DirkMD - Free CMIO Perspective

Cutting Healthcare Costs by Making A Better Brick

2012-01-14T01:33:00.002-05:00

1. THE BRICK

An interesting question I get asked is, "Why don't all order sets look the same at every hospital, even for the same disease?"

This question can be posed in several other ways, including :

"Why can't we just use order sets from someone else?"
"Why can't we just use canned order sets without editing them?"
"What do your policies look like?"
"Why can't we just use canned policies?"
etc...

But all of these basically ask the question, "Why isn't this standard?" and, of course, the follow-up question is, "Why is every hospital re-inventing the wheel?".

For inspiration to answer this question, I'd like to first explain a little bit about a wonderful thing : The brick.

According to the Wikipedia article, bricks have been in use since about 7500 BC to help construct things. (It's actually a really interesting article - If you appreciate human civilization, the brick has played a big role in building our streets, aqueducts, houses, walls, etc...)

The reason the brick is such a useful thing, from a design standpoint, is because it has two features :

A brick has a fairly predictable shape that allows you to easily arrange them to connect two or more places in space.
A brick is designed to withstand a particular load.

You'll notice these two features are helpful when designing any system - Having basic units engineered in a predictable manner, which can be assembled to make a bigger, more complex system that achieves a certain goal.

Hospitals contain systems that are also made of smaller units - Order sets are made of orders, clinical pathways are made of order sets, charts are made of notes, policy manuals are made of policies, etc.

Unlike a physical brick, however, all of these basic units are conceptual - They are mostly complex documents - not physical objects - so it's a little harder to tell how predictable they are - e.g. to know if they're not engineered exactly the same.

For example, with physical bricks, it's much easier to tell if one hasn't been engineered exactly the same as the others :

You can immediately and obviously see the entire system is off, and locate the offending brick quickly.

But real bricks are not 100% predictable - They all have some degree of imperfections between them -As a kid, I occasionally ran into bricks behind our grade school, or around landscaping projects - I think I could only stack about 10 of them on top of each other before they start to fall over. (Legos are about the only bricks I can think of that are engineered to such a high standard that you can stack virtually hundreds of them on top of each other and still have practically a straight wall.)

But because regular bricks in the real world have subtle imperfections, humans have developed a tool we can use to compensate for these imperfections : Mortar, or cement.

Mortar/cement only works, however, to help straighten out the system when our brains get involved - We see the system leaning, so we set up guidelines/markers to help determine what is straight, and we put down the mortar/cement to compensate and correct the system. Again, the compensation depends on our human brain.

Because documents are not physical objects, we may not see the system leaning - But it can lean the same way in a conceptual manner. Fortunately, our brains can still compensate for a lot of conceptual leaning.

So in my job in clinical informatics, I look at the standards by which the "document" bricks are built - To determine just how standard they are, and how much people's brains are compensating.

And this is why hospitals all have order sets that look and behave slightly differently - Because there aren't national standards by which their bricks are engineered. Fortunately, human brains are filling in the mortar.

What would it take to get all hospitals to engineer exactly the same bricks? The same engineering standards at all hospitals.

And what would it take to get all hospitals to engineer bricks as well as Legos? An engineering process that was detailed enough to ensure that every brick looked virtually identical.

So why don't all hospitals have the same engineering standards and engineering process? Because documents, unlike bricks and Legos, are not as easily understood/studied/observed as physical objects. And because, for better or for worse, human brains can compensate extremely well - So there is little pressure to engineer them exactly the same.

So as a result : Every hospital is re-inventing the wheel when it comes to their processes and their documents. In almost every hospital, they are looking to achieve exactly the same goal (in brick terms, "bear the same load") - Delivering standardized but customizable, evidence-based, high-quality care. But because the engineering standards and processes are not defined nationally, their tools are all ever-so-slightly different, and so virtually every hospital has to engineer them slightly differently.

2. A NEW IDEA ON CUTTING HEALTHCARE COSTS

The number of people employed to re-engineer all of these tools is remarkable. And it doesn't just include order sets - It includes every document in a hospital, virtually everything I mentioned in the CMIO's Checklist - Order sets, policies, protocols, documentation/forms, templates, etc. And all of these tools have to be continuously updated to reflect best practices, new technology, new evidence, etc.

These operations have become part of the price of healthcare - Continuously re-engineering all of these tools, so that the front-line doctors and nurses have the best and most up-to-date :

Policies and Procedures to learn from and operate by
Orders to take care of patients and deliver care
Order sets to standardize and expedite the ordering process for a common clinical scenario
Clinical Pathways to standardize care for a common clinical diagnosis
Protocols to standardize and automate care for a common clinical scenario
Guidelines to help standardize outcomes for a common clinical scenario
Documentation tools to record and transmit data about care, and guide their thinking
Templates to help them standardize and expedite the documentation process
etc...

Unfortunately, keeping up with all of this information, and managing it, is very challenging for most hospitals. The professional industry term for this is "document management", and hospitals that do this well will probably have an easier time in the next five years than hospitals that do this poorly.

So to help hospitals struggling with this, I have often wondered why nobody publishes national, standard definitions of these tools, so that we could at least have the same engineering standards, and maybe then the same engineering processes - So that the order sets would all look the same - And you could truly use the same order set at any hospital...?

I suspect the reason that no regulatory body currently wants to offer these standard definitions is this : Anyone who tries to introduce these definitions and engineering standards nationally will have a big operational and financial challenge : 99% of hospitals would suddenly have to re-tool all of their documents to meet these national standards. Imagine the cost to healthcare nationally.

But so then I wondered - could we do something like this on a much smaller basis, in a much slower, more controlled manner?

Again I'll mention our Interstate 91 Informatics project - Where a bunch of volunteer Informaticists along the Interstate 91 Corridor here in New England are starting to meet regularly to talk about our common informatics issues. As I mentioned in a previous post ("Can we do better than SOAP?"), we are going to start talking about ways to standardize our documentation on a regional level. I'm interested to hear people's responses because it could be very interesting if, in the next step, we looked at standardizing our definitions, engineering processes, and engineering standards. Would it allow us to share resources that ultimately saved all of our hospitals money, and reduced the cost of operations and care in the entire region?

Stay tuned!

My belief is that we are all both teachers and students our entire lives - So I love to hear people's feedback and thoughts. Feel free to leave comments or questions - Always glad to entertain any new or interesting ideas!

Rethinking Prescription Writing Standards (SIG)

2011-12-22T00:46:00.000-05:00

So I train a lot of doctors on electronic medical records. I'm always interested to learn how doctors think about their medication orders. How do they write them? Do they understand them? Do they know who reads them? How does that order get to the patient?

One of the areas of prescription writing I'm particularly interested in is the SIG: section of a prescription. (For some of the basics of a prescription, see this excellent Wikipedia article.)

"SIG" is medical shorthand for "Signa", which in Latin literally means, "write". In simple english, it basically means, "Please write these instructions for taking the medication : _________________"

(Huh? Why not just write "Instructions : _____________" - I mean, don't we have printed pads? Is ink too expensive?)

Anyway, some examples of "SIG:" shorthand commonly seen on prescriptions include :

SIG : 2 tabs PO q6h prn (IN ENGLISH : Two tablets by mouth every six hours as needed)

SIG : 40 mg PO BID (IN ENGLISH : Forty milligrams by mouth twice daily)

SIG : 1 patch TD daily (IN ENGLISH : 1 patch topically daily)

Why do doctors write this bizarre latin shorthand? I'm not sure, but it sure is short to write. For more details on this medical shorthand, Wikipedia has this article on prescription shorthand - Some of these I'm not even familiar with as a practicing physician.

Does this shorthand help patients understand how they're supposed to take their medications? Not really. So we need pharmacists and nurses and other health professionals who help interpret this.

As a linguist, I'm also puzzled - Here we have a writing that allows communication from doctor to pharmacist, and doctor to nurse, but not doctor to patient. Why does this language exist?

One of the more fascinating parts about this communication is that here seems to be some confusion about "BID", "TID", "QID", etc. versus q12h, q8h, and q6h.

First, some background about this :

QD - In Latin : Quaque Die - In English : means "Once a day"
BID - In Latin : Bis In Die - In English : means "Twice a day"
TID - In Latin : Ter In Die - In English : means "Three times a day"
QID - In Latin : Quater In Die - In English : means "Four times a day"

These are so pleasant, and potentially difficult to read (depending on handwriting), that they are falling out of favor and being replaced with their English equivalents.

Then, there is the q___{time} designation, like :

q2h = Every 2 hours
q4h = Every 4 hours
q6h = Every 6 hours
q8h = Every 8 hours
q12h = Every 12 hours
q24h = Every 24 hours
q48h = Every 48 hours

What I find interesting is the common question, "Should I write this medication QID or q6h?"

I. THE DIFFERENCE BETWEEN QID AND Q6H

Ever heard of the story of the patient who asks the pharmacist, "My doctor says I should take this medication four times a day - Does that mean I need to wake up in the middle of the night to take it?"

What this speaks to is some confusion about the difference between the two. Often, doctors use the two interchangeably. But while in most patients the clinical difference is minimal, they are very different to nurses and pharmacists. Here it is :

QD, BID, TID, and QID actually have very specific times attached to them.

QD = usually 08:00am
BID = usually 08:00am and 20:00pm
TID = usually 08:00am and 12:00noon and 20:00pm
QID = usually 08:00am and 13:00pm and17:00pm and 22:00pm

When I say usually, I mean it - Many hospitals have slight variations to this schedule. As an example of how challenging this can be, some hospitals publish their own standard medication timing guidelines like this which try to help standardize these times. Ask your hospital pharmacy what their standard med administration times are!

The one thing that is pretty standard about all of these (QD, BID, TID, QID) in virtually all hospitals is that, as much as they might vary, they're all usually during waking hours. None of them would technically let you take a dose at 4am.

q2h, q4h, q6h, q8h, q12h - DO NOT have specific times attached to them.

In other words, if you write to give a medication every 12 hours, the actual time it will be given will depend on what time you write the order : If you write it at 5am, then the medication will be given at 5am and 5pm. If you write it at 7am, then the medication will be given at 7am and 7pm.

Of course, if you wanted it to be given at 8am and 8pm, but you were writing the order at 5am, then you could write "q12h START TIME : 08:00am"

This is why it's not uncommon to see as-needed pain medications written as "TID PRN" - Many doctors are not even totally aware of the difference between TID and q8h. Of course, in most of these instances, if a patient were to go to the doctor and ask "Can I take it at 4am for pain if I need to?", the doctor would often say "yes".

Clear as mud? The good news is that with most medications, being an hour or two off means little in terms of the amount of drug in the blood - So it really doesn't make much difference from a clinical perspective.

But this language sure causes some confusion. Do we really need this Latin shorthand? Who is it helping?

II. RETHINKING THE SIG

So today at work, I was rethinking the sig :

And it's interesting - I noticed that in about 90% of prescriptions :

PRN (as needed) medications : Often use q____h PRN _________________
Standing (regular) medications : Often use QD, BID, TID, QID

This makes sense - Generally, docs don't want their patients waking up regularly to take medications at 3:00am.

So I wondered : Could we leverage this pattern to help with electronic order entry?

And then I wondered : Instead of this alternate, Latin-based language which allows doctor-to-nurse and doctor-to-pharmacist communication, but no doctor-to-patient communication ...

could we make a language that everyone (doctor, patient, pharmacist, and nurse) understood equally well?

III. THE COGNITIVE FRAMEWORK :

It seems the real division is between regular (every day) medications and PRN (as needed) medications.

As I mentioned :

EVERY DAY (REGULAR) : COMMONLY USE QD, BID, TID, QID
AS NEEDED (PRN) : COMMONLY USE Q___h PRN ____________

So could we use this to shorten the length of options commonly seen in EMRs for medication frequencies?

And then when doctors, nurses, and hospitals are trying to collect medication histories with the simplest, smallest number of clicks, instead of thinking of :

[ Medication Name ] [ Dose ] [ Route ] [ FREQUENCY ] [ PRN ] [ REASON ]

could we instead cognitively think about medication orders like this :

[ Medication Name ] [ Dose ] [ Route ] [ PRN ] [ FREQUENCY ] [ REASON ]

???

This would allow us to re-consider, re-evaluate, and redesign our forms!

IV. THE SAMPLE SCREENS :

And so a draft paper form could potentially look something like this :

And this would allow us to set up the electronic documentation of a single medication according to this form where you could "just click on options" :

And so for about 95% of medications, this would allow you to enter medications very easily! For example, Lasix 40mg PO BID could instead be : ("Lasix 40mg" + 3 clicks)

Or Percocet 5/325mg PO q6h PRN moderate pain (4-6) could be : ("Percocet 5/325mg" + 2 clicks + "moderate pain") :

Or one could even expand the PRN reasons, to turn that same percocet order into "Percocet 5/325mg" + 3 clicks) :

and this could be a form that physician, pharmacist, nurse, and patient could easily comprehend to all speak the same language.

It also guides a physician to avoiding the small issue of "Percocet 5/325mg PO TID PRN mild pain".

And for those other 5% of medications where either there are unique medication times, or when you absolutely need the patient to take the medication every 6 hours and start at 03:00am, you could still click the "FOR OTHER INSTRUCTIONS" box all the way at the right.

I just thought I would share some ideas of how you can help fix your med reconciliation forms and possibly your med reconciliation EMR software, to promote clarity and help reduce clicks. Who knew medical informatics could be so much fun!

Would love comments! Anyone have any other thoughts about the subject? As always, education is a priority, and discussion is welcome!

Van Halen and why Informatics is not IT

2011-12-14T22:33:00.002-05:00

One of the things you get asked commonly, when you work in informatics is, "Are you an IT guy/gal?"

Informatics is commonly confused with IT (Information Technology). But the two are very different. Allow me to explain.

Definitions about informatics vary widely, but I personally take the everyman's, common, "Ernest and Julio Gallo"-type approach - It shouldn't be something that's scary, unapproachable, or unaffordable. I hope to deliver good informatics to your dinner table at a reasonable price in a way that everyone can enjoy. So when I had the opportunity to help, I added the part about "right information to the right person in the right place at the right time in the right way" to the definition in the Wikipedia article on informatics (academic field). Just sounds so much simpler, approachable, and friendly.

This definition still won't make sense to many people, but I'll say this : Informatics may have nothing at all to do with computers. Yes, often informaticists often use computers in their jobs (while planning to save the world!), but some of my favorite examples of informatics have nothing to do with computers.

1. THE FIRST EXAMPLE
The first example of informatics without IT comes from a business professor I had back in college, who did informatics consulting for businesses. He told us this story of a large, popular European furniture company with a quality problem they were having.

The issue, he said, was this : The company had a table they were selling which was often getting returned. Why? "MISSING HARDWARE!" was the most common reason reported by unsatisfied customers.

The company had tried several times to fix the problem on their assembly line, to no avail. Despite their best efforts to remind workers to put all the right pieces in the box, the workers still sometimes forgot.
So reportedly this informatics consulting company examined the assembly line closely :

They focused on Worker #4, who apparently was in the area where the problem arose. His task was to take the Type A bolts out of bag A, the type B bolts out of bag B, and the Type C screws out of bag C, and put them all in the box. But when they studied him, they noticed : He was occasionally forgetting to put in the Type A bolts, occasionally forgetting the Type B bolts, and occasionally forgetting the Type C Screws.

The trick was to get him to remember to put in all three types, every time.

How to do this? They looked to establish something informaticists generally call "cognitive feedback" or "visual feedback" - Where a person gets some immediate feedback/verification of, "Have I done the job right?". And they found the solution in the factory lunchroom, where reportedly the lunch trays just happened to have three pockets in them :

Using a magic marker, they labeled each pocket with an A, B, and C, to create a tool to provide the factory worker with cognitive feedback during his part of the assembly line.

So now instead of taking from bag A and putting it in the box, bag B and putting it in the box, and bag C and putting it in the box - They told him to put from bag A into the tray, bag B into the tray, and bag C into the tray :

Voila! This provided immediate visual feedback/confirmation to the worker that "Yes, you have remembered all three", allowing him to then dump the tray into the box, knowing the task had been completed properly.

And as the story goes, after this change, their quality problems disappeared. All for the price of a $4 lunch tray. The table reportedly ended up being a big hit.

2. THE SECOND EXAMPLE
The second example of Informatics without IT was given to me by the same college professor, who used to do informatics consulting. He was hired to study the waiting times at a large fast-food burger chain. Their issue : "We are losing customers, and can't figure out why." Customers told the chain : "Service is too slow", and no matter what the company was doing to speed up operations, they were losing customers.

This business professor gave me some good informatics advice that still sticks with me today : "The first trick to knowing how to fix a system is knowing how to crash it. Once you know how to crash the system, you'll know how to fix it."

So apparently he and his buddies spent a whole week trying to crash one of this burger joint's restaurants.

They tried spilling food in the middle of the restaurant. No go - Someone came and cleaned it up.
They tried yelling really loud and carrying on. Didn't work. The workers called the police and they were escorted out.
They tried ordering very slowly at the counter. Didn't work. Another cashier opened up and the line moved along.

Then they paid very close attention to the crowd during lunch, and heard someone take advantage of the resaurant's jingle at the time : "Hold the pickles, hold the lettuce, special orders don't upset us." The order they heard?

"Um, I'll have a double cheeseburger, extra-well-done, with extra lettuce, no tomatoes, no onions, ketchup but no mustard, extra pickles."

The restaurant handled this order just fine, but his team noticed that if the person said the order loud enough, during a busy lunch crowd, suddenly everyone else wanted their burger done their way.

So they tried it out the next day, during a busy lunch hour : Two or three of his team ordered their custom burgers, loud enough that people towards the back of the line could hear. It set off a chain reaction that slowed the restaurant to the point where the line went out the door. Customers left in frustration.

Their advice to the restaurant : Lose the jingle. It's OK to allow customers to do custom orders, but if you advertise it, you're only asking for trouble.

So they got rid of the jingle, and reportedly the waiting time went down, and satisfaction went up.

3. THE THIRD EXAMPLE (ROCK & ROLL!)
The third example comes from popular rock and roll culture. Ever heard of the 1980s-1990s rock band, Van Halen?

Van Halen : Informatics Pioneers?

Ever heard of the popular mythology of their concert contract demanding they have no brown M&Ms in their dressing room? As a child of the 80s, I remember hearing about this - It became a little joke of rock-n-roll culture, even parodied in movies like Wayne's World when Wayne gets to walk backstage at the Alice Cooper concert. It's the inside joke of roadies and concertgoers everywhere.

Get ready - It's not a myth! TheSmokingGun.com even has an actual copy of the Van Halen contract rider, which you can read by clicking here. But rather than just juvenile rock-star excess, both TheSmokingGun and Snopes.com go on to explain the real purpose of this request :

The issue was that the band was touring with some very hefty equipment : Large light shows, elaborate sets and music, etc - And there were a lot of technical errors happening. The girders couldn't support the weight of the sets. The flooring would sink in. And despite their contract having very clear instructions of what it would take for the band to perform safely, it seemed people weren't reading the contracts fully.

So by adding the clause :

"Article 126 : There will be no brown M&Ms in the backstage area, upon pain of forfeiture of the show, with full compensation."

it allowed the band to quickly determine if the contract had been read in detail, to give them some confidence that all of the technical specifications had been met.

In other words : They had immediate cognitive/visual feedback about the adherence to the contract and performance of the safety design. An easy way to see failure before it happened!

What genius! (I know David Lee Roth later became an EMT - I wonder if he's involved in HealthIT today?)

So ask yourself : What are your brown M&Ms, and can they help your safety discussions?

It's all about getting the right information, to the right person, in the right place, at the right time, in the right way - Doesn't necessarily have anything to do with computers at all. And hopefully by doing that, you'll help save the world. (Or at least make it a little better place to live.) :)

Again, I always welcome comments! Feel free to leave thoughts or ask questions - I'm always glad to ponder the imponderable!

Rethinking electronic documentation filters

2011-12-02T23:41:00.001-05:00

"Life is a series of hellos and goodbyes, I'm afraid it's time for goodbye again..."
- Billy Joel, Songs in the Attic, 1981

So I was thinking more about the challenges with electronic documentation. As I mentioned in my last post, I'm thrilled that people are going to be seeking ways to transmit notes to each other, but I'm just not convinced we have agreement about *what* to send and *when*.

The problem is that healthcare reform is going to center around documentation. So documentation is going to become more important than ever. Knowing :

What and when to document - and...
How to find the right information quickly

... is becoming a key survival skill for hospitals and doctor's offices.

So for today, I wanted to ponder #2 above - (I'm going to ponder on #1 in my next post...)

As part of my job, I teach docs about how-to-find-the-information-they're-looking for. Most EMR software has some system of "filters" you use to narrow down your search to exactly what-you-need.

Sometimes those filters, and learning to use them, can be a little complex, and it's not always the most intuitive. So I wondered - How can we make it more intuitive? I wondered how *I* would graphically re-think a chart - If the chart is all about a patient's life, then why not start with a simple timeline?

(Of course, since we don't really ever know when the end will be, we can just assume the line will have "TODAY" listed on the other side from "START".)

Anyway, during our lifetimes we will all have interactions with people - That's what we want to record. The goal of the medical chart is to document all those interactions.

Some relationships will last for varying lengths of time, all generally starting with a "HELLO" and a "GOODBYE".

It's funny - I think as human beings, our brains tend to remember the "Hellos" and "Goodbyes" much more than we remember the stuff in-between. Anyway, in clinical terms, that "HELLO" is either an "Admission H&P", an "Intake Note", or some sort of a "Primary Evaluation" - And the "GOODBYE" is a "Discharge Summary", "Transfer Note", or some other type of "Signoff Note" :

But of course, if you're following that person regularly, you check in from time-to-time throughout the duration of your relationship. In "best-friend" terms, that's a "stop-by-for-a-visit" or "chat on Facebook". But in clinical terms, these "check-ins" are your progress notes :

The challenge then in documenting your life is that you will have to manage the information about these sorts of ongoing relationships for many people in your life :

And so if they all have an Admission-type note, several progress notes, and a discharge-type note - You already have a large amount of data to keep track of.

And making things more complex is that other people in your life will only be brief but still-important encounters - The cashier you met while withdrawing money while on vacation, the dermatologist you saw once to burn off a wart... Some of the people you interact with in your life will just be single encounters :

Finally, I think it's also important, when re-thinking the medical record, to remember that a patient's life will be punctuated by changes in level-of-care. As long as you have some kind of health coverage, you will always be in one level-of-care or another. (It's even debatable - If you have no insurance, could you still be in an "outpatient setting"? Deep philosophical questions for the healthcare informaticist!) So if we look at the patient's life from this level-of-care perspective, there are definite punctuations which are immediately useful at understanding clinical activities in time :

And so, whoever tries to comprehensively document the life of a patient will have a very complex issue to untangle - Who documented what, and when? :

Fortunately, I think most people think intuitively when inquiring about a patient's life - You either want the whole story, or a part of it. And how much you ask for will depend on your need. Want to admit them for a psychiatric admission? You might be interested in their first childhood pediatric notes. Have a "frequent flyer" you know well? You might just want the notes from the last few levels-of-care. And with computers, it's fairly easy to draw a box over the time period and notes (colors) you want :

Of course, this is somewhat of a jumbled mess - But if the user could help arrange the order of the colors they wanted, they could sort out the mess (by their own individual preference), and then by dragging one box :

... you could quickly select :

The timeframe you need (X-axis)
The notes you need, by your general and immediate preference (Y-axis)

Of course, the colored lines above make it sort of complicated (would some users interpret this to mean the patient had all of these people in their lives throughout the duration of time?), so maybe you would prefer to be able to check off the notes (by profession) you want, as you make your query for documentation :

... and so in this way, you could quickly get to the notes you want - In time, using levels-of-care as a marker, and by specialty. (But remember a common problem with electronic documentation : Sometimes you WANT the doc to see "REALLY IMPORTANT" stuff from a specialty they didn't think to look for, e.g. Case Management, physical therapy, chaplain services - In the paper world, those "REALLY IMPORTANT" things were usually done as a "sticker on the chart" or something like that... It's a little trickier to do that sort of thing with an electronic chart. Who gets to decide what's "REALLY IMPORTANT"?)

OF COURSE, making this sort of a search filter available for your own medical record would depends on some of the following factors :

Having a common (or at least steady) patient identifier, so that someone will be able to assemble all the documentation from all of these different clinical people you interact with.
The ability to mark documentation with not only the author, but the profession/specialty they represent.
Being able to mark changes in level of care across a healthcare delivery system.

... so I'm not counting on seeing this in any software tomorrow - But I think it's potentially another way to look at the mass of information about a patient and quickly get what you want in an intuitive way.

REMEMBER : WITH FREE OPINIONS, YOU GET WHAT YOU PAY FOR. :) Always glad to hear from people - Feel free to leave thoughts and comments! :) In my next post, I'm going to ponder about "How much documentation is enough?" - Stay tuned! :)

Can we do better than SOAP?

2011-11-15T21:39:00.001-05:00

So I've recently been looking at some of the most important standards we have, that few people appreciate. Some standards that I've recently been admiring the beauty of :

The 110-volt AC plug in America - Thank goodness for this! Imagine if you had to worry about which coffee maker you could or couldn't buy because it didn't have a plug that fit your house! (Or even better, think about how challenging it is to travel with that same coffee maker to a different country!)
Traffic lights - Thankfully, they all behave the same in our country. Imagine if driving from Maine to Florida meant having to learn different traffic signal patterns?
Traffic patterns - We all drive on the right side of the road in the U.S. - Imagine having to change as you drove state-to-state? (I wonder how they handle this in the Chunnel between France and England?)
Train tracks - Snopes.com has this interesting debunking about railroad gauge, that includes a mention of how during the American Civil War, the northern railroads had one gauge while southern railroads had multiple gauges - this was argued by historian James McPherson to be one of the logistical factors that contributed to the Union army winning over the Confederate army. (And interestingly, after the North won the war, many of the southern railroads were rebuilt by the North, giving us the American standard of 4 feet, 8.5 inches.
The Apple iPhone/iPad/iPod charger - Although Apple toyed with some of the charging pins since the iPhone 3G, the plug has essentially been the same since the original iPod in 2001. Now it seems that since the iPhone 3G, you can use the same plug to charge your iPhone 3G, iPhone 4, iPhone 4S, iPad, iPad2, iPod Touch, and various other apple devices. I suspect this is why the plugs are becoming so ubiquitous that most of my friends now seem to have one in the kitchen just to let visitors charge their Apple devices.
American Standard Code for Information Interchange (ASCII) - This is arguably much larger than just an American standard - Although Unicode has expanded the ability for designing documents, ASCII is probably the most widely-used standard in computing. Can you imagine if your processor didn't know you pressed the "A" key on your keyboard? What if that "A" didn't show up on the screen? What if you sent an email and the "A" didn't arrive?
Internet Protocol (yes, both versions 4 and 6) - The Internet would not be possible without a standard Internet Protocol.

So I think we can all agree that these standards are good for us - And thankfully for healthcare, the ANSI (American National Standards Institute) created a new HITSP chapter in 2005 after the ONC recommended someone start working on healthcare IT standards. (A shout out and thanks to John Halamka, MD for taking on this labor of love!) :)

Anyway, I think the take-home message about healthcare IT standards is that we're still really early in the process. (As of this writing, the HITSP has only been around for about 6 years!)

So because a lot of my work as an informaticist deals with the struggles to achieve standards, I think a lot about the final objective of informatics : Getting the right information to the right person in the right place at the right time in the right way. (It's easy to get 2 or 3 of those right, but getting all 5 right is much more difficult.)

Anyway, so it's nor surprising that I eagerly await the day when the Regional Extension Centers (RECs) and Implementation and Optimization Organizations (IOOs) finally make the HIEs that smoothly link our electronic medical records - ... But what then?

A WORD ABOUT STANDARDS FOR CLINICAL DOCUMENTATION

In my quest to get the right information to the right person in the right place at the right time in the right way, it dawns upon me that the best technical solutions may still fall short of expectations because of this : There aren't really any good standards for the content of electronic documentation.

In fact, I started to ponder - What standards are there, at all, for clinical documentation?

Most practicing physicians can pretty quickly think of one real standard - The SOAP note. It stands for "Subjective, Objective, Assessment, and Plan", and is a rough outline for how you write a note in a logical way :

S - Subjective - What you heard from the patient (history, opinions, and answers)
O - Objective - What you saw about the patient (measurable things or physical findings)
A - Assessment - What you believe is currently going on with your patient
P - Plan - What you and your patient are going to do about it

The SOAP note is also a cognitive framework for how we think and communicate about patients - When you sign out to another physician, the SOAP note influences our thinking and what we say or write about our patients. By forcing a physician to confront the evidence (S, O) before rendering an opinion (A) and plan (P), it has had a remarkable impact in improving the quality of care and communication about that care.

Interestingly, the history of the SOAP note goes back to this seminal paper written by Dr. Lawrence Weed, published in the March 14th, 1968 edition of the New England Journal of Medicine. (Click on the link above to read the actual article.)

** IF YOU WORK IN HEALTH INFORMATICS, YOU SHOULD READ THE ORIGINAL ARTICLE IN ITS ENTIRETY. **

One of the fascinating parts about this article is in its opening paragraphs - The purpose of this paper, in 1968, was "...to develop a more organized approach to the medical record, a more rational acceptance and use of paramedical personnel and a more positive attitude about the computer in medicine." Snark Alert : Amazing how far we've come in the last 43 years!

But getting back to serious discussion, the paper highlights many of the struggles we have had with implementing EMRs in the last 40 years - And still continue to struggle with today. When you read the article and see how notes were structured BEFORE the SOAP structure, you can see why some people argue he should win a Nobel Prize for Medicine.

It's also good to know Dr. Weed is still developing his argument, as published in this 1997 British Medical Journal article. (THANK YOU DR. WEED!)

But then I thought : We have the SOAP note - But do we have anything else to help guide us?

Since most medical schools teach little about clinical documentation (you're usually too busy learning about diseases), many doctors finally learn about note writing from pocket books like the Washington Manual Intern Survival Guide. (Similarly-themed but shorter "Intern Survival Guides" can be found here and here, just to get an idea of what I'm talking about.)

So if most of our education for physicians about writing notes falls down to these pocket guides, and the notes are often specialty-dependent but built on the SOAP framework - It's no wonder we all struggle with electronic documentation.

A WORD ABOUT THE STRUGGLES OF ELECTRONIC DOCUMENTATION

Anyone who has worked on electronic documentation will tell you : It's hard to build, and hard to maintain.

The first challenge is getting a note built - What exactly will you use the note for? What will you name it? What do you want to include in the note?

Looking for answers to these questions often depends on :

The planned clinical scenario
The physician's experience
The physician's pocket guide they learned from in Internship
Regulatory and compliance issues (the stuff that insurers and other regulators want to read about)

The funny thing is, every hospital is working on this same problem separately - Often coming out with similar but slightly different results. It's a great example of "everyone rebuilding the wheel".

Why can't all Medicine History and Physicals look the same? In my experience, most of them approximate the same SOAP format, but I've even heard the argument, "I'd like to see the Plan at the TOP of the note when I read it." This speaks to a challenge of documentation in general -

Documentation is closely tied with our cognitive processes.
Our cognitive processes, while similar, are not entirely standardized.
Regulations, insurer demands, and clinical practices change frequently, making it important to maintain notes after they're built.

So in the end, clinical documentation is more expensive to build and maintain than most people imagine - And every hospital is having the same struggles together.

And because the notes may vary in their end result - An electronic note sent from a doc in one hospital one day may not have the best reception by the physician at another hospital.

In other words : I'm thrilled we're working to link our EMRs - But will the notes we send be equally effective at another hospital?

THE INTERSTATE-91 INFORMATICS PROJECT

So we have a new, small, informal group of volunteer healthcare informaticists here along the Interstate 91 Corridor that stretches between New Hampshire/Vermont, all the way down through Massachusetts to New Haven, CT. We meet informally every 3-4 months for dinner to discuss healthcare informatics, and I'm glad to report we recently obtained a donated website, which we hope to develop.

I'm hoping at our next dinner to propose a few crazy ideas to our group :

What if all of our documentation looked the same? (for the same clinical scenario...)
Could all of our clinical documentation look the same? (for the same clinical scenario...)
Could we develop a standard for content of electronic documentation?
Could we help further develop the SOAP note, to provide a logical and cognitive standard that helps improve care and reduce costs for all of us?
Could this framework be used as a teaching tool about clinical documentation in medical schools and residency programs?

Will let you know how things turn out after our next dinner. Look out for the I91 Standards. :) (Ooh, another cliffhanger, I know!)

As always, I love to answer questions. Feel free to respond with thoughts, questions, ideas, or other discussions. Remember : Education is a priority! :)

#SpeakFlower : A model for interconnectivity in US Healthcare

2011-10-15T00:21:00.001-04:00

UNIQUE IDEA ALERT

So in my last post, I discussed the "patient identifier problem", and how it contributes to poor connectivity between systems. I discussed some of the political problems with sharing health information, and some common, differing perspectives. I also briefly discussed some of the models being developed, including NHIN/Direct (now officially called "The Direct Project").

One thing I forgot to mention that makes this all more complicated are the myriad of privacy laws - Not just HIPAA, but also various state laws about transmitting or even storing data about HIV and other transmissible diseases.

The challenge is then, how do we overcome these issues in the US?

There are a lot of issues to be worked out, clearly, but I think one of the major issues is simply making organized change with all of these political, financial, and technical obstacles in place.

I. WHO'S THE BOSS?

So let me first ask - Who's the most powerful person in healthcare?

I sometimes ask friends and family this question, and it's interesting to hear people's guesses. "Obama?" "Hillary Clinton?" "The insurers?"

My response : It's the patient.

I think people forget : The patient is the boss. They are the ones who pay the tab for healthcare, whether it's the insurance premiums they pay, or the taxes they pay... They are the one making the choice about where to go, and so they have enormous influence about who succeeds in healthcare.

When it comes to healthcare reform, there is often talk about laws, and doctors, and insurance companies, and nursing unions, and medicare and medicaid - But I think patients are an untapped resource in the healthcare reform discussion.

The problem is that, from my experience, a lot of patients are sort of like the substitute teacher we all had in grade school - Even though they are technically in charge, they're new, they just showed up today, they don't entirely understand the routine, and so they sometimes lack confidence and can be subject to "But-Mrs.-Smith-we-ALWAYS-have-three-hours-of-recess"-type arguments that sometimes steer them.

So I've often wondered - What if a group of coordinated, informed patients could really assert their power?

II. COORDINATING A CHANGE

The problem is, as I said, most patients are too new, or too inexperienced to know what to look for. When doctors and nurses become patients themselves, they can be some of the most challenging patients - Why? Because they know what to look for and how to assert their power.

So then I wondered - Could we somehow train all patients to know what to look for? Could we get patients to ask for different care? How would they know what to ask for?

So I thought - To help patients assert their power to make change, we need to make it easy for them to ask for change.

So then I thought of solutions. For those readers who are multi-lingual, or amateur linguists, you'll appreciate this : Language is fluid. It's not as precise as most people think. Even though modern English has been around since about 1550, linguists know this : words enter and leave the lexicon all the time.

So what if we employed a linguistic feat and came up for a new word for this new type of healthcare? Something evidence-based, efficient, affordable, and connected?

How could we get patients to ask for this type of healthcare? What if we could get lots of patients to ask for this type of healthcare?

III. DEVELOPING THE STANDARD FOR INTERCHANGE

The first trick is, defining a standard for this future model. From the ground up, the new healthcare paradigm has to be built. The informational framework for healthcare has to be laid to allow hospitals to run efficiently, and for patients to be able to - only if they wish - bring their data with them. That is, one patient = one chart. So when a patient moves from one office to another, the systems will talk to each other and allow true data portability - Without having to push or pull the data.

Why would a patient want a standard for data portability? Why would they care that other doctors can read their chart from another hospital?

It reduces errors (because doctor A knows what doctor B has been doing)
It reduces unnecessary tests (because doctor A knows what doctor B already ordered)
It reduces costs (because fewer tests means lower bills)
It reduces waiting times (because doctors don't have to spend time trying to research your history)

What if we could make a standard for data portability? Obviously, many patients would refuse, citing personal privacy reasons - But would other patients ask for this?

IV. THE SPEAKFLOWER PROPOSAL

The next trick would be, naming the standard something easy. A lot of "Health IT standards" have names like HL7, CCR, CCD, LOINC, DRG, ICD-9, etc.... Not too tangible to the average patient.

But what if we named this standard something really warm and friendly and tangible... Like "SpeakFlower"?

In other words, "SpeakFlower" is a placeholder for a standard that allows a patient to ask for a doctor/hospital/office to have all of their medical records transferred to a central site that the patient controls, so that other doctors could look at it in the future. It means not only building a particular HealthIT standard into the EMR, but also adopting the practices needed to employ it.

Could we get patients to ask for SpeakFlower? What if they did?

V. SELLING THE CONCEPT

The joke goes, "Standards are like toothbrushes - Everyone knows what they are, but nobody wants to use yours." We have lots of different EMRs, and a few standards, and yet there doesn't seem to be universal agreement on which standard to use, and how to use them.

Why? I think there are a lot of reasons - Complexity of our healthcare system is one, but there's also privacy issues and a lot of competing financial interests. In the end, fighting for a national standard is very challenging.

So what if a coordinated group of patients developed a 100% optional, national standard and how to use it? And what if they called this optional standard SpeakFlower?

Could we sell this concept of an optional national standard? I think so.

After developing the SpeakFlower technical framework (HealthIT standards, central servers, HIPAA-secure gateways, etc.) - You then need to teach patients about SpeakFlower. And how to do this?

Imagine a commercial on the Superbowl, where Wilford Brimley comes out and says :

"You know, my primary care doctor almost ordered something that interfered with something my cardiologist gave me last week, because she didn't know what my cardiologist had prescribed. And my cardiologist almost ordered a test I had last week in the ED because he didn't know what the ED doctor had done. And all of these extra tests, bills, and waiting time are really getting me down... But now, with SpeakFlower, all of my doctors can share my information easily and I get to keep track of it. So ask your doctor... Do you SpeakFlower?"

Why Flower? Because flowers are ubiquitous. They come in every shape and size, are found in every country in the world, and no matter what it looks like, it's still a flower. Flowers are friendly, peaceful, and represent growth, life, and vitality. This optional standard that patients might ask for should represent peace and life.

Oddly enough, if you diagram the model that puts the patient at the center of the medical record, and have all of the providers/hospitals/labs/pharmacists as connections to the patient in the center - The diagram almost invariable ends up looking like a flower.

Why speak it? Because like a person trying to communicate in a foreign language, we might ask for someone to speak the language we know. Asking to SpeakFlower is asking a doctor/hospital's EMR to speak a particular language - It says, "Please have your EMR speak the language I need to accomplish the goal I'm asking for."

VI. REALLY?

The hope would be that simply discussing an optional, national standard for healthcare data interchange would be enough to get all vendors, doctors, and hospitals to adopt the standard and implement it for those patients wanting their charts to be portable. It would also help simplify the privacy discussion, because patients would actively seek out SpeakFlower - Makes the whole discussion on "opt-in-or-opt-out?" much simpler. It would also allow docs and hospitals to generally keep their legacy systems - Implementing SpeakFlower does not require painful amounts of programming, just adherence to the SpeakFlower standards.

But if the discussion wasn't enough, then the hope is that the Wilford Brimley commercial on the Superbowl could spur the discussion - in the same way pharmaceutical companies have gotten patients to ask for drugs, patients could start showing up saying, "Dr. Stanley, do you SpeakFlower in your office?" and have an understanding of the benefits of SpeakFlower.

And even if 30% of my patients asked me to SpeakFlower, I'd probably have little choice but to make sure my EMR SpokeFlower, for those patients requesting it. So I'd speak to my vendor and ask them to make sure my EMR can SpeakFlower.

VII. SPEAKFLOWER TODAY

If only...

There is a SpeakFlower.org web site, which I started to develop with two colleagues in our spare time, but you'll notice the web site is outdated and quite frankly, we realized planting SpeakFlower in our national garden would require much more time and capital than we currently have. (Namely, weekends and nights.)

But we're still trying to build it and transplant it to the right FlowerPot. Our hope is to make SpeakFlower a force of good in healthcare. We also have a #SpeakFlower hashtag on Twitter that we apply to tweets that discuss patient-centered electronic medical records.

Healthcare needs innovative ideas. If you're interested, follow @SpeakFlower on Twitter, feel free to use the #SpeakFlower hashtag, and look for the SpeakFlower gardening team as we look for the right pot to plant in. :)

As always, I welcome any comments and thoughts.

"Why don't these systems talk to each other?"

2011-09-19T22:47:00.000-04:00

Another frequent question I get asked in my job is, "These systems are all plenty expensive - Why don't they talk to each other?"

What this is referring to, of course, is the common phenomenon that the EMR at one hospital may not seamlessly transfer a patient's record to another EMR down the street.

There are actually a few reasons why this is so, but one of the most interesting ones is a phenomenon called the "patient identifier problem."

Q: DIRK, WHAT EXACTLY IS THE "PATIENT IDENTIFIER PROBLEM"?

Here's what it boils down to : It's much harder to identify a human being than you might imagine.

Allow me to explain. (Names below are purely fictional, just for teaching purposes.) :)

So at first glance, it should be easy to identify a human being. After all, we have names, right? When we see our neighbor John mowing the lawn, riding his mower - His name is John - We recognize him - Yep, that's him. Easy, right?

Well the problem is what happens when we actually try to identify someone on paper - That is, have a record that we can match to an actual human being.

At first, we might try to label a chart "John's Chart". The problem with this approach is that there may be lots of Johns, so in a small town (even on a small street), you might have two "John's Charts".

So you might add the last name : "John Smith's Chart". This might work in a small town, but when you expand to collect charts for your whole state, or the whole country, you might find over 700 "John Smith's".

So names are generally a bad way to label a chart for a few reasons :

There might be over 700 "John Smiths" across the country - How will you know which chart is the right one to look for?
Your neighbor, John Smith, might register at Clinic A as "John Smith", at Clinic B as "Johnathan Smith", and at Clinic C as "Jon Smith". This could potentially make three records. How will you know which is the proper record to search for?
Names may also be misspelled by registration staff - If a "Karen" registers in a clinic, will the registration staff write "Karen", "Caryn", "Karin", or "Karyn"?
Ethnic names, over a large country, also may suffer from the poor understanding of the host country. How exactly does one spell Dimitry? Dimitri? Dimytri? Moroch? Morocz?

So one might try to straighten this out with some simple recipe - One I often hear first is, "Why not use the first three letters of the first name, first three letters of the last name, and the date of birth?"

The problem with this approach, again, is that someone might register with a different name in a different clinic. Is it going to be "JOHSMI01011970" (John) or "JONSMI01011970" (Jon)?

Then the suggestions usually continue...

Q : "Dirk, what about by the Medical Record Number?"

The medical record number for this patient at your hospital (123456) may not be the same as the medical record number for the office down the street (654321).

Local medical record numbers might work for a hospital, or a small regional group (if you have centralized registration), but they generally don't work across different healthcare systems.

Q : "Hmmm... Why not use the social security number to identify people?"

The social security number suffers from a few problems too :

There is no check-digit in the social security number. A check-digit is a number (or series of numbers) that are mathematically linked to the other numbers, so you can figure out if the number has been falsified. The social security number was invented back in 1935, before things like "identity theft" were around. As a result, the social security number is probably one of the most abused identifiers, often used for fraud by criminals.
The social security number is a 9 digit number - So in total, we should be able to issue about 999,999,999 of them, BUT... because of certain restrictions (e.g. no numbers that start with 666, no numbers with -13- in them, no numbers with all of the digits the same), there is really only a pool of about 820 million to draw from. Currently the U.S. population is about 350,000,000. Which sounds OK, except that we maintain that number by having some people die every year, and some new babies added every year. In total, about 620 million numbers have already been handed out, so we could potentially run out of social security numbers sometime around 2100. Yes, that will be some time from now, and hopefully we will be able to fix that before it happens - but in our current political climate, will the government ever be able to assign a personal identifier again?

It's funny - I've spoken to informatics people around the globe, and they usually ask me "Dirk, why are you guys in America having so much trouble getting a national health record? In our country it's very simple - Either :

"...our national government maintains our national health record."
... or ...
"...our national government assigns a health identifier for all citizens."

Well, the problem is that we're Americans. Authors like George Orwell and Ayn Rand have left a significant impression on our national consciousness. We just don't like the idea of the government assigning a number to track all of our health information. In fact, in 1998 Congress forbade the HHS, by law through HIPAA, from creating a health information identifier - Despite many groups asking for an identifier, and an estimated $77 to $154 billion savings in healthcare that a national patient identifier could provide. And perhaps (just to be fair), this is for good reason - see this letter opposing government-issued medical identifiers and this document summarizing the potential abuses. (Please note : I'm not taking sides, just presenting both sides of the argument.)

Q : "So Dirk, how does the VA (Veteran's Administration) do it? I heard they saved lots of money through their VISTA/CPRS medical record, and their record is a major source of data for reasearch."

The VA essentially has a national patient record because, well, most veterans have a different opinion. When you ask most vets, "Do you care if the government has a number to track you?", they say things like "No, the government has been keeping a file on me since the day I enlisted!" right before they rattle off their rank and military ID number from memory. In reality, the VA has also been using Social Security numbers, but I understand there is currently a movement underfoot to move away from those identifiers to another number - I'm not an expert on the VA architecture, but this might explain why they divide the VA record up into different VISN systems. (Any VA Informatics people reading this willing to help explain the architecture?)

In short -

The culture at the VA supports a nation-wide medical record number.
The culture of private and teaching hospitals (the "rest of America") does not.

This is why, when I get asked :

Q : "Dirk - The VA has free EMR software - Written by the government, so it's public domain - Why don't private hospitals use it?"

I usually answer, "Private hospitals *could* use it, but because of these culture differences they probably wouldn't see the cost and efficiency benefits that the VA did."

(In reality, there are also other support reasons why a private hospital might not implement CPRS/Vista - But that might be changing some with cool open-source projects like OpenVISTA.)

Q : "So Dirk, is there any hope for a national EMR? Will patient data ever be truly portable?"

Well, currently there is the NHIN/Direct project (see http://www.directproject.org and http://wiki.directproject.org) which seeks to allow physicians to transmit patient data, securely, between different offices - But without a common patient identifier, this may not have the workflow some patients and most physicians ideally want. Still, it would allow a maximum of privacy and patient control, and it's at least a step in the right direction.

There are also a number of regional Health Information Exchanges currently in use, and new ones being built - But without a common patient identifier, nobody seems to be sure about how this is going to work on a bigger, national level.

So yes, if you're traveling from Texas to NYC for vacation - You had probably better bring your medication list and medical history written on a piece of paper, just in case you need medical care.

Finally - I think there is actually some hope for a solution to this that could fly politically in America. I've tested the idea with both republicans and democrats and oddly, both seem to like it. It's called the voluntary patient identifier. Unfortunately, I think so far this effort suffers from poor understanding, poor marketing, and quite frankly, poor patient interest.

But I think there is a way to change that - I'll describe it in my next post.

(Ooh - Cliffhanger ending!) :)

Always glad to share - Feel free to leave comments, thoughts, and questions! :)

Where Exactly Do My Med Orders Go?

2011-09-15T21:57:00.001-04:00

Where Exactly Do My Med Orders Go?

Ever wonder where your orders go? One of the things I do when training a doc on CPOE is explain to them the basic medication delivery workflow in a standard hospital. When a doc "goes CPOE", he/she is suddenly confronted with some hard realities of the ordering process - Exactly what they order, and exactly how they order it, will largely determine their success in getting a drug at the right time in the right place.

(PLEASE NOTE WITH THIS DISCUSSION : YOUR MILEAGE MAY VARY GREATLY - This workflow is a general summary, but lots of other hospitals may do things differently, and for a very good reason - I'm just summarizing some general themes, but for specific information, ask your directors and informatics staff.)

So I usually start to frame the discussion with the basic unit of care - A doctor, and a patient. (You'll notice these slides borrow from my piece on "What is Med Reconciliation, anyway?", where the physician and patient lovingly spend time with each other in an area I call the "patient care cubicle") -

Inside a hospital, this "patient care cubicle" is an "inpatient care cubicle".
Outside a hospital (or in an ambulatory setting like an ED or day surgery), it is an "outpatient care cubicle".

Let's focus first on the inpatient care cubicles, where a lot of medications are ordered as patients are admitted into a hospital :

It's first important to consider how exactly an order is created. If the doctor and patient are sitting next to eachother, then the basic unit of care (from the physician perspective) is the physician order - On this slide, it's labeled the "MD ORDER".

First, let's look at this "MD ORDER" for a medication in the INPATIENT setting :

I. MD ORDER FOR A MED : THE INPATIENT SETTING

There are then basically three different ways a med order can come into existence :

As a written order - This is an acceptable way of making an order - Even the VA, during downtimes, allows written orders. Most hospitals with EMRs still allow some form of written orders for downtimes or other complicated orders. The problem : This type of order requires a nurse or pharmacist to transcribe it, so if the doctor has poor handwriting, this can result in a small percentage of error.
As a telephone / verbal order - This is also an acceptable way of making an order, especially if the physician's hands are tied up doing a procedure or surgery. The problem : This type of order also requires a nurse or pharmacist to transcribe it, so if the doctor doesn't speak clearly, this too can result in a small percentage of error. ("Did you say Metoprolol 15 or 50mg?") Another problem : This legally requires a physician to go back and sign this order afterwards - This is very complicated and time-consuming for most physicians.
As a CPOE order (Computerized Physician/Provider Order Entry) - This is the entry method preferred by most hospitals, regulatory bodies, and the government. I suspect this is primarily because there's no intermediary who needs to transcribe the orders, so there is the common belief that this is less error-prone. I haven't seen really good data about this yet, but I do believe that good CPOE requires good training. There is also some data to suggest total medication turnaround time decreases with CPOE use - See this HHS piece on Medication Turnaround Time.)

So no matter how a physician creates the order on the floor, the order gets made. Let's say, for our little example, that the order is "Ativan 2mg IV x1 dose STAT".

Any idea where the order goes next? If you guessed "Pharmacy", you're right!

Whether you're in an electronic hospital, or a paper hospital, Joint Commission requires all inpatient medication orders for acute care hospitals to be "verified" by pharmacy. ("Verify" is basically a fancy word for "double check".)

So a pharmacist suddenly sees the medication order - "Ativan 2mg IV x1 dose STAT". And there are a few things a pharmacist can do to try to help ensure the safety of this order :

They can check the allergy profile of the patient.
They can check the dose of the drug.
They can check for drug-drug interactions.
In some hospitals, they can even sometimes do fancier checks, like check the renal dosing of the drug, weight-based dosing of the drug, etc. (this sometimes varies considerably, depending on the types of services offered)

What pharmacists can't really do well is verify the need for the drug - They usually aren't sitting in front of the patient, with the patient's chart - So if you order heparin on a patient with a bleeding ulcer, a pharmacist is probably not going to be able to prevent that type of error. (Nurses, usually right in front of the patient, are generally much better at finding that sort of error.)

Anyway, after a pharmacist does his/her best to verify the safety and dosing of the order, or adjust the order, they generally click a button to "verify" the order, and then the order travels back to the floor where it does two things :

It unlocks the Pyxis drawer (in this example the Ativan drawer)
It creates a blank entry on the eMAR (electronic Med Administration Record, aka Cardex, aka Codex)

This then allows a nurse to take the drug out of the Pyxis drawer, give the drug, and chart it on the eMAR. Once it's charted, that's generally when a hospital gets to generate a bill for having given the drug.

So that's generally the way it works in the inpatient world.

Any problem with this pharmacy verification workflow? Having a pharmacist double-check the orders helps reduce errors, so ... Is there any drawback a doc should be concerned about?

Well, imagine if you had a patient seizing in front of you, and you had to give them the "Ativan 2mg IV x1 dose STAT". How long exactly does it take a pharmacist to verify those medication orders?

The interesting thing is that there are actual guidelines about this (these are approximate - Your state/region may vary on this) :

Priority = STAT : In many places regulations allow up to 30 minutes (in reality, most inpatient pharmacies verify STAT orders in about 5-10 minutes)
Priority = ROUTINE : In many places regulations allow up to 90 minutes (in reality, most inpatient pharmacies verify ROUTINE orders in about 10-15 minutes)

So if the regulations are typically around 30 minutes, and even if your inpatient pharmacy can do it in 5 minutes, can you wait 5 minutes to give a seizing patient ativan?

The answer, of course, is obviously no. So what can you do? You generally have two choices :

OPTION 1 : Call the pharmacy and say "I just put in an order for Ativan - Can you verify it ASAP so the nurse can take it out?"
OPTION 2 : BYPASS the system. In most hospitals, a "Code Blue" (or "Rapid Response") is a perfectly acceptable reason for a nurse to hit the "Emergency Bypass" button on most Pyxis machines - This allows a nurse to get the drug and give it in an emergency.

Note that most Pyxis machines actually TRACK the number of times they have had an emergency bypass - There should be a valid reason to bypass this important safety mechanism, so a unit where there are more emergency bypasses than needed/expected may be a cause for concern and investigation.

So that's generally the way medication orders get created, verified, and followed in an inpatient setting.

II. MD ORDER FOR A MED : THE OUTPATIENT SETTING

Here's where it gets interesting - That pharmacy verification thing? Joint Commission, on seeing the success of this in reducing errors, thought 'Wouldn't it be nice to have pharmacist verification in the OUTPATIENT setting (e.g. Emergency Department, Surgical Daycare, etc?)'

And do you know what happened? Most emergency departments, for good reason, argued "We can't handle the time delay of verification!" - And so, as of yet, it's not a mandate to have pharmacy verification in the Outpatient setting. (Perhaps for good reason - The delays it could cause could create a whole different set of problems.)

So how exactly *does* it work in the outpatient setting?

ORDERING : Generally the same process - A doctor can use either :

Written order (same as above)
Telephone / Verbal order (same as above)
CPOE order (same as above)

The difference is, however, that without pharmacy verification, where exactly does the order go?

In most hospitals with electronic systems, then, this order then will simply go to the eMAR. (It makes a space in the software for charting the administration of the drug.)

So then the typical workflow is this :

Nurse sees order in EMR or eMAR
Nurse opens Pyxis (in most EDs, the Pyxis will open up automatically)
Nurse gives the drug
Nurse charts the administration on the eMAR

Again, after charting the administration, this usually lets a hospital generate a bill for having given the drug.

So in most Emergency Departments (mostly for reason of avoiding delays), there is no pharmacist between the doctor and the nurse part of the workflow. There are still two people double-checking every order - The physician, and the nurse.

III. SO WHY DO I CARE?

The reason you, as a physician, might care about these workflows is that often, inpatient doctors are asked to admit patients from the Emergency Department.

And how exactly does a computer know which workflow to follow - The inpatient or outpatient workflow?

Let's recall - In both settings :

The physician usually places the order via written, telephone/verbal, or CPOE methods.
The nurse usually gives the drug to the patient
The nurse usually charts the administration on the eMAR.

So how does the computer know whether to follow the inpatient or outpatient workflow for a medication order?

Q : "Dirk, is it by physician type? Like, orders from ED docs follow the outpatient workflow, and orders from Hospitalists or other inpatient docs follow the inpatient workflow?"

A : Usually not. If systems were built to do that, then a Hospitalist would have significant challenge in running a code on a patient physically located in the ED.

The answer is usually, as we say in New York, "Location, location, location." That is, the location of the patient determines which workflow most EMRs will use on the order.

So for example - A patient in a location, and the workflow :

ED Room 1 = Outpatient
ED Room 2 = Outpatient
ED Room 14 = Outpatient
ED Holding Unit = Inpatient *
Room 125B = Inpatient
Room 202A = Inpatient
ICU Bed 3 = Inpatient
ICU Bed 4 = Inpatient

* - Remember - Most holding unit beds are actually an inpatient level of care, and so they follow the inpatient workflow.

IV. AGAIN - WHY DO I CARE?
There are a few reasons why I teach this to the docs I'm training on CPOE. They are :

You are going to be a working doc - You need to know how to troubleshoot the system, just in case of emergencies.
You might admit someone from the ED to an inpatient bed.

Reason #2 is especially important for Hospitalists and other inpatient docs to understand. Why? Because if you are admitting a patient, and the computer still shows the patient to be in an ED bed (e.g. ED Room 1), then those orders entered into your EMR may not be verified by pharmacy - Orders not verified by pharmacy means the Pyxis machine won't open up when the patient gets up to the floor. This is when you get that call from the nurses : "Dr. ____________, remember those orders you put in while the patient was in the ED? For some reason, the Pyxis machine isn't opening up now - Can you re-enter those orders in the computer?"

This, of course, leads to delays and frustration. So what's the best thing you can do as an inpatient doctor, if you get called by the ED to admit a patient to your service?

1. First, go down to the ED and see and evaluate your patient
2. Look on the computer at their location -
- If it says "ED Room 1" - Ask your registration to change their bed to an inpatient location.
- If it says "ED Holding Unit" or "125B" or "204A" or "ICU 3" - Go ahead and start your orders.

Again, please remember - Your hospital's workflows may vary - This is a gross generalization for teaching purposes only. Please ask your local regulatory agencies, your local administrators and directors, and your local informatics people for more details about the workflows in your hospital.

Hope you enjoyed this post - Feel free to send questions, I love the feedback and I'm always glad to create posts to answer them!

Informatics Curriculum for Medical Schools

2011-08-01T00:07:00.000-04:00

There are currently lots of hospitals and doctor's offices looking to "go electronic" by getting an electronic medical record.

Some of those offices/hospitals, however, won't be able to make the conversion without a lot of pain.

Why can some places do this easier than others?

Part of the reason, the one that's commonly given, has to do with willingness to change - Will you be willing to support your EMR implementation? Will you pay for the software AND the support? Will you be willing to send your doctors and nurses for training? Will your doctors and nurses embrace the change?

And then there is another more difficult topic - Is your clinical paperwork well-designed?

Organizations that have well-designed paperwork will generally have an easier time of "going electronic". Organizations that don't, won't.

So what is "well-designed paperwork?"

This brings me to a topic that sometimes pops up in clinical informatics discussions - The need for some education on clinical informatics in medical school.

Medical schools already have so much to teach - So whatever informatics education I can convey has to be short and sweet. So I started to dream of what I would teach, if I were invited to lecture at a large medical school, to help the students with their medical careers and running their practices/hospitals in a way that facilitates an easy transition to an EMR...

Doctors who generally understand these tools and design their paperwork by these divisions will have an easier time "going electronic". Doctors who mix these tools on the same paperwork will have a harder time "going electronic".

(So without further ado... Start the spacey, dream-sequence fuzzy-image noise...!)

--- START OF CURRICULUM ---

CLINICAL INFORMATICS 101 - LECTURE SUMMARY

Instructor : Professor D. Stanley

Date : Now

Location : The comfort of your computer

Hi folks - Nice to meet you. I'm here to prepare you for thinking in a way that will help you in your future clinical practice.

No matter what you do clinically, you're going to be expected to work in a team. Good teamwork requires good communication. So it's really important, for you, your patient, and your other teammembers, that you know how to communicate properly.

In addition to being friendly, and well-spoken, and being a good listener - It's very useful for you to understand the informational tools you're going to be using to take care of patients.

So I'd like to tell you a little bit about those tools, so that you design and use them well.

1. ORDERS

An order is an instruction for a defined person to deliver a defined type of care to a defined patient in a defined way for a defined amount or duration. You'll notice I used the word "defined" five times in that sentence. It's because orders, to be safe, should be as well-defined as possible. Orders are the smallest unit of initiating patient care. (If you're going to be a doctor, you're going to be creating a lot of them, so you should learn to make them safely.)

One of the first mistakes people make is mistaking other things for orders. As a general rule, orders should not be more than a line long - If they are, it's usually a red flag that what you're writing may not actually be an order.

In the paper world, putting other things down as orders isn't so bad because human brains will still be able to sort through the different types of tools, and nurses will know what to do with them. In the electronic world, however, poor order organization will lead to difficult EMR installations and HealthIT implementation problems.

Generally, orders are categorized by the people who are expected to follow them. So for example, you might find :

A. Pharmacy/Medication Orders - Used by nurses and Pharmacists

B. Nursing Orders - Used by Nurses

C. Diet Orders - Used by Nurses and Dietary Staff

D. Respiratory Orders - Used by Nurses and Respiratory Therapists

E. Activity Orders - Used by Nurses and Physical Therapists

F. Laboratory Orders - Used by Nurses, Phlebotomists, and Laboratory Staff

G. Imaging Orders - Used by Nurses and Radiology Tech staff

Another common mistake : Writing protocols as orders. Protocols are any "if-then" statements you might think of writing - If it's got a condition, where you expect a nurse to interpret a condition before taking another action, it's a protocol. For example, "Give aspirin 325mg PO x1 dose STAT unless patient is bleeding" is actually a protocol. Even the text "These orders are only to be used while the patient is in radiology" is actually a protocol.

And another common mistake : Writing patient instructions as orders, e.g. "Change catheter dressing every 7 days after discharge" might sound like a nursing order, but it's really an order to the patient.

Some examples of good and bad orders, with comments :
- Aspirin 325mg PO x1 dose STAT - good order
- Morphine 2mg IV q30min PRN moderate pain - Because it has no duration, this could be a dangerous order if it's not automatically re-evaluated in 2-3 hours
- Morphine 2mg IV q30min PRN moderate pain x 3 hours - By assigning a duration, this becomes a safer order
- Morphine 2mg IV q30min PRN moderate pain x 3 hours Comment : Hold for sedation - By adding a comment reminding the nurse to hold the drug if the patient becomes sedated, this becomes a safer order
- Aspirin 325mg PO x1 dose STAT Comment : Hold if patient is bleeding - Because there is a conditional (IF/THEN) statement, this is actually a protocol.
- Change catheter dressing every 7 days : Unless the patient is actually in the hospital for 7 days or more, this is more likely a patient care instruction than a nursing order.
- Chest X-ray STAT : While this might be acceptable, it does not contain an indication and there may be billing problems. It also does not tell a radiologist what you are looking for, so they could miss what you're looking for.
- Chest X-ray STAT Indication : Cough, sputum, acute shortness of breath, rule out aspiration - By adding an indication, this will avoid billing problems. By adding detail, the radiologist can cue in on the clinical question you're asking.
- Advance diet as tolerated - This does not help a nurse understand what diet they should be aiming for, nor how to advance the diet, nor in what timeframe they should try to advance it. Because this actually has a great deal of IF/THEN logic, in short, this is really a protocol.
- Advance diet to regular diet as tolerated - This helps a nurse understand that you're aiming for a regular diet - Better than the above diet order, but it is still a protocol.
- Advance diet to regular diet, no texture modification, no liquid modification as tolerated - This is even better because it tells a nurse what diet to advance to AND the texture and liquid modification that the patient might need - But from an informatics perspective it is still a protocol.
- If K+ < 2.5 then give KCl 40 mEq PO x1 dose - First, because it has an IF/THEN, this is actually a protocol. Next, writing "KCl 40 mEq PO x1 dose" could be misread as "KCl140 mEq PO x1 dose".
- If K+ < 2.5 then give Potassium Chloride 40 mEq PO x1 dose - Still a protocol, but at least there's no chance for the "l" in "KCl" to be mistaken for a 1.
- Percocet 5/325mg 1 tab PO QID PRN - Some folks might not realize that QID actually has set times - 8am, 12pm, 4pm, 8pm - So technically this could only be taken during daytime hours. (Is that the intent?) The PRN also does not specify the reason to take the Percocet, so a patient could take it for any pain. (Is that the intent?)
- Percocet 5/325mg 1 tab PO q6h PRN - This is a little better, because it would allow a patient to take it every six hours, even overnight. Still does not describe the circumstances in which the doctor would recommend to take the Percocet.
- Percocet 5/325mg 1 tab PO q6h PRN moderate pain (4-6) - This is even better, because the PRN is better described, so the nurse/patient knows when to consider giving the Percocet.

The best way to know whether or not an order is a good or bad order is to test the order in a test environment - Have a doctor write or enter the order on a "dummy" patient, and have a nurse read it. Then interview the nurse about how they would act and what they would do. It also helps to ask someone with experience/training in ordering safety.

The take-home point : Orders should always be well-defined for safety. Always test them if you have any questions.

2. ORDER SETS

Order sets are groupings of orders used to standardize and expedite the ordering process for a common clinical scenario. Unlike protocols, order sets contain orders that are started, modified, and stopped by a physician/LIP.

For safety and proper functioning, order sets should only contain orders. (See above.) Protocols, policies, procedures, guidelines, patient instructions, and staff instructions should generally not be built into order sets.

Optimally, for efficiency, order sets should be divided into one of three categories :
- a. - Admission order sets - Those that standardize the ordering process for a common admitting scenario.
- b. - Diagnosis order sets - Those that standardize the treatment for a common diagnosis/procedure
- c. - Convenience order sets - (e.g. "Quick pick" lists) - Those that standardize the ordering process for a common clinical objective not described in a. or b. above.

3. CLINICAL PATHWAYS

Clinical Pathways are groupings of order sets used to standardize the treatment of a common clinical diagnosis. They contain orders which are started, modified, and stopped by a physician/LIP, and are generally used daily throughout a patient's hospitalization.

4. PROTOCOLS

Protocols contain orders which are started/modified/stopped by a nurse, pharmacist, or other healthcare professional based on a well-defined condition. They contain the IF/THEN logic that helps automate and standardize a clinical process, and if well-designed, can actually help increase safety and efficiency.

The challenge with protocols is designing them well. Because they contain orders which are started, modified, and stopped by a nurse, pharmacist, or other healthcare professional based on a well-defined condition ("discrete data element" in informatics terms), they require significant safety evaluations.

Common examples of protocols might be the "Heparin titration protocol", the "alcohol detoxification protocol", and even the "PPI Substitution protocol". These should all be published in a similar manner, executed in a similar way, and re-evaluated continuously.

5. GUIDELINES

Guidelines are general instructions about how to accomplish a particular task, but have much less medicolegal weight than a protocol or policy/procedure. Guidelines are generally more flexible, and can be useful for a clinician to understand a clinical process but still allow modifications depending on clinical circumstances.

6. POLICY/PROCEDURE
A policy is a written standard of the organization. A procedure is a set of detailed steps which describe how to achieve the policy objective. For this reason, they are commonly published together on the same document, although technically, a procedure does not have to be a mandated standard.

As a rough outline, policies are usually divided into :
- Clinical Policies (and procedures) - Those that describe standards related to patients and patient care
- Administrative Policies (and procedures) - Those that describe standards related to employees and employee issues.

Because policies and procedures should be 'written with maximum clarity for them to be effective, they generally should only be written by people with experience or formal training in policy writing.

For easy access, policies and procedures should be published in a common, easy-to-access area.

Algorithms can be thought of as graphical representations of procedures.

7. DOCUMENTATION / FORMS
Documentation/Forms are the tools used to record patient condition, vitals, responses, therapies, and outcomes in date/time order. If designed properly, these can also help standardize clinical processes and streamline care. Types of documentation can include :
- Notes (e.g. H&P, discharge summary, nursing notes, respiratory therapy notes, etc.)
- Checklists
- Consents
- Flowsheets (e.g. vitals, pain, drips, vents, etc.)
- Labs
- Radiology/Imaging
- Other technology results

8. STAFF EDUCATION MODULES
A Staff Education Module is a document that teaches a staff member about a particular educational objective. It could contain text, photos, videos, or other tools needed to communicate the educational objective to someone else. For effectiveness, it should contain a short quiz to document understanding of the educational objectives.

9. PATIENT EDUCATION MODULES
A Patient Education Module is a document that teaches a patient about a particular educational objective. It could contain text, photos, videos, or other tools needed to communicate the educational objective to a patient. For effectiveness, it should be very clear, and should contain a short quick to document understanding of the educational objectives.

10. CLINICAL STAFF SCHEDULES
A clinical staff schedule is a document that outlines the employee(s) responsible for patient care at a particular date/time. It should be published in a standardized manner in a standardized location.

11. TEMPLATES
A template is a document used to help build, standardize, and expedite the building of another document. Some common examples might include the "Order set template", the "Admission H&P Template", the "Discharge Summary Template", and the "Policy Template".

Because templates can be used to expedite and standardize the creation of another document, great care should be taken to avoid "auto-documentation"-type workflows which can run into billing/legal issues.

12. GLOSSARY
A glossary is a document with a list of commonly-used terms in alphabetical order, along with their definitions. By having an organizational glossary in a common area, it allows all members of the organization to standardize their definitions and language.

--- END OF CURRICULUM ---

I hope this was useful to you all - Again, your mileage may vary greatly, so please check with your local laws and regulatory bodies before setting up your own paperwork and processes - but from a functional, pure-informatics standpoint, these would be the chapters in my "clinical informatics book".

Feel free to write with any comments or questions - Discussion on this blog is always welcome! :)

Secret weapon of the Informaticist : Good policy writing

2011-06-25T00:13:00.001-04:00

I've been speaking with various CMIO types, and Informatics types, and found an interesting pattern :

"Newbies" - Generally focused on the technology, the software, the bells-and-whistles
"Grizzled Veterans" - More focused on governance and change management.

In short, it's probably helpful if you have a little bit of both characters. You will need to worry about the software, the menus, the dialog boxes, the MLMs, your hosting, and your tablet computers if you want to garner support for your EMR implementation.

But when it comes to making organizational impact, nothing beats being a solid policy writer. A smart policy writer can have much more influence than the best politician/salesman in trying to organize things.

So even though I've written about policies before, I thought I'd write a little bit about the "tricks of the trade". This is the little trick you'll want to keep hidden, your lightsaber you'll carry on your belt. Only wield it when needed, and only use it for good.

POLICY TRICKS OF THE TRADE

The first thing, to really get solid with policy writing, is to really grok what a policy is. (For those of you who don't know the word "grok", it comes from Robert Heinlein's book, "Stranger in a Strange Land" - Wiktionary defines it as "to fully and completely understand something in all its details and intricacies.".)

A policy is your opportunity to set a standard. It's a document defining the standard.

The procedure (often linked to a policy by being on the same document) is the steps you take to achieve that standard.

Profound! You could, in fact, write a policy saying that you will be brought a coffee and donut every morning when you show up for work!

What would such a policy and procedure look like?

POLICY : All readers of Dirk's Blog will be brought a coffee and donut on their arrival for work in the morning, according to the procedure outlined below.

PROCEDURE :

Minion will bring money to store at 7am.
Minion will purchase (1) large coffee with cream and sugar.
Minion will purchase (1) chocolate glazed donut.
Minion will transport coffee and donut (described above) to office.
Minion will await arrival of Dirk's Blog Reader.
Minion will give donut and coffee to Dirk's Blog Reader, on their arrival.

It's really as simple as that. And yet, it's complicated...

It's complicated because people don't generally think that clearly without training. It's really easy to get clouded up, especially in healthcare, where you are trying to satisfy many regulatory issues, and dealing with very technical procedures.

But alas, I'm here to provide some guidance!

THE POLICY

The basic format of a policy can be written using this template :

[ who/what ] will [ what ] [ how ] [ when ] [ where ] [ why ]

Where : (blue = mandatory, brown = optional)

[ who/what ] = The person/thing that is being standardized

[ what ] = The standard that is being applied to the who/what above

[ how ] = How the standard will be achieved ("according to procedure below" is OK!)

[ when ] = Optional, only use if it helps clarify when the standard should be applied

[ where ] = Optional, only use if it helps clarify where the standard should be applied

[ why ] = Optional, only use if it helps clarify the purpose of the standard

Try it out! Here are some examples of good policy statements :

All patients will receive low-fat meals.
All patients over age 60 will receive a pneumonia vaccination before discharge.
All policies will be clearly written, according to the procedure outlined below.
All order sets will be evidence based and built according to the procedure outlined below.

And some examples of bad policy statements :

Patients should receive low-fat meals because it helps prevent heart disease. (Wordy, and never use the word "should" in a policy - "Will" is a stronger word!)
Pneumonia vaccines are helpful in preventing pneumonia, and so this will be given to any susceptible patients over age 60 before they are discharged by the nurse. (Too unclear and wordy!)
It is imperative that policies should be written in a manner consistent with easy comprehension. Policies should be developed in a clear, logical manner. Policies will be kept in the policy manual after approval. (Too wordy, vague, and starts to put procedure into the policy statement!)
All order sets will be evidence-based. (Nothing pointing a reader to the procedure below which, hopefully, explains how to build them in an organized fashion.)

Once you've mastered writing a good policy statement, you can proceed to the procedure.

THE PROCEDURE

The procedure is the "how to achieve the goal."

The best way to write a clear procedure is, again, to explain the who, what, when, where, how, and why, which together will tell you "how to achieve the goal".

Again, a template for thinking about it - You will need a series of steps :

[ who ] will [ what ] [ when ] [ where ] [ how ] [ why ]
[ who ] will [ what ] [ when ] [ where ] [ how ] [ why ]
[ who ] will [ what ] [ when ] [ where ] [ how ] [ why ]
[ who ] will [ what ] [ when ] [ where ] [ how ] [ why ]
[ who ] will [ what ] [ when ] [ where ] [ how ] [ why ]
... and so on ...

Where :

[ who ] = Person who will actually perform the task

[ what ] = Task they will perform

[ when ] = (usually optional) when / until when they will perform it

[ where ] = (usually optional) Where they will perform it - Only use if needed for clarity

[ how ] = (usually optional) How they will perform it - Use only if needed for clarity

[ why ] = (usually optional) Why they will perform it - Use only if really needed (rare)

Think of it as a recipe - In fact, most recipes are procedures! From Allrecipes.com you can find this New York Cheesecake Recipe and easily convert it to a procedure :

Baker will preheat oven to 350 degrees
Baker will grease a 9-inch springform pan
Baker will, in medium bowl, mix graham cracker crumbs with melted butter
Baker will remove mixture from medium bowl and press mixture onto bottom of springform pan
Baker will, in a large bowl, mix cream cheese with sugar until smooth
Baker will blend in milk
Baker will mix in eggs one at a time
Baker will mix in sour cream, vanilla, and flour until smooth
Baker will pour filling into prepared crust
Baker will place crust and mixture into preheated oven for 1 hour
Baker will turn oven off and let cake cool in oven with the door closed for 5-6 hours
Baker will remove cake from oven and chill in refrigerator

Of course, seeing all of the "Baker will..." statements is sort of cluttered, so you might make it look a little tidier :

Baker will :

preheat oven to 350 degrees.
grease a 9-inch springform pan.
in a medium bowl, mix graham cracker crumbs with melted butter
remove mixture from medium bowl and press mixture onto bottom of springform pan
in a large bowl, mix cream cheese with sugar until smooth
blend in milk
mix in eggs one at a time
mix in sour cream, vanilla, and flour until smooth
pour filling into prepared crust
place crust and mixture into preheated oven for 1 hour
turn oven off and let cake cool in oven with the door closed for 5-6 hours
remove cake from oven and chill in refrigerator

And of course, in healthcare, this can be even a little more complicated, because you may have multiple characters. If you do, then you just have to separate the characters based on the role they will play in achieving your policy standard. For example, if the policy goal is "All dance performances by Fred Astaire and Ginger Rogers will leave audiences happy", then your procedure might be :

A. Fred Astaire will :

approach Ginger Rogers on dance floor.
listen to current music
choose dance style that is appropriate for current music.
lead dance that is appropriate for music.

B. Ginger Rogers will :

follow dance led by Fred Astaire.
demonstrate amazing dancing.
smile for audience.

C. Audience will :

observe talented dance performance by two dance superstars.
applaud after dance performance is completed.

IN CLOSING

Remember, the key to good policy and procedure writing is clarity. Less is often more. "Generous use of white space" is what was recommended to me once. It takes some practice, but once you learn the pattern to good writing, it doesn't need to take too long. In fact, you eventually get to the point where someone is discussing a problem, and you can start to envision the policy and procedure in the top of your head.

This is why good policy writers are worth their weight in gold - Good policies can help you make change, achieve clarity, and save your organization time and money. Bad policies do not make any organizational change, do not achieve any clarity, and will cost your organization in both time and money.

I hope this helps turn you into a policy ninja! Remember, use your powers only for good, and go out there and write good policy!

Would love to hear other people's stories about writing policy and how it related to their EMR implementations! If anyone has any questions, please let me know! :)

Are physician informaticists cost-effective?

2011-04-12T23:13:00.001-04:00

Another common question you get asked in informatics, especially as a physician is, "Do we really have to pay a physician to do this work?"

This is certainly a valid question - In times when budgets are tight, it's important to question why an organization is paying a physician to do informatics work.

I'm going to present the case about why I think a physician informaticist is cost-effective.

I. BACKGROUND : HOW TO MAKE A CHANGE

The first thing you need to know, to understand the argument, is "How do I make a change?"

To answer this, I'd like to break down the roles you played when you sent your last email - After all, the purpose of all email is to help make some sort of change (either "to own a book from Amazon" or "to inquire about renting a house") :

1. Owner
2. Builder
3. Tester
4. Approver
5. Publisher
6. Monitor

"What's that?", you say? Yes, you actually did all of these roles.

1. Owner - You subconsciously decided, "I need to send an email" and "I will be responsible for what I write" and "I will follow-up on the success of the email."
2. Builder - Based on your decisions, you started to draft an email
3. Tester - You decided to proofread the email before you sent it, to see if it met your quality standards.
4. Approver - After proofreading, you decided "This email is good enough to use!"
5. Publisher - You published the email by clicking "SEND".
6. Monitor - You waited for a response and checked your return emails to see if your email was successful. If needed, you might go back to Step #1.

To make a change in a clinical setting, you basically have to do the same steps, but since you're doing it for someone else, there is a crucial extra step you will need :

1. Owner - Person who owns the tool
2. Builder/Informaticist - Person who designs the tool with the Clinical IT Analyst
3. Tester - Person who tests the tool to "make sure it works as designed" before approval.
4. Approver - Usually a committee who examines the purpose, and the testing data, and approves the tool for use
5. Publisher - Person who publishes the tool for use in the clinical setting (EMR or Printshop)
6. Educator/Implementor - Person who trains clinical staff on the tool - Educates them about how it's published (where to find it), and how to use it.
7. Monitor - Person who monitors the success of the tool after it's implemented, and troubleshoots any problems

And finally, to get to the full list of responsibilities required for designing / testing / implementing clinical tools in the electronic era - there are two last players we will need :

Clinical workflows are notoriously difficult to analyze, and so it's helpful to have a Subject Matter Expert, who answers detailed questions about clinical operations and evidence-based practices.
Clinical IT systems are very complicated (much more so than sending an email), and so we will need a Clinical IT Analyst to know the programming needed to build these clinical tools, together with the Informaticist. (This role was not needed in the "paper world".)

So this brings us to the final roles that need to be filled to make a successful change in the technologically-advanced clinical setting :

1. Owner - Person who owns the tool
2. Builder/Informaticist - Person who analyzes the workflows and develops standardized tools in conjunction with the Clinical IT Analyst
3. Clinical IT Analyst - Person who develops standardized tools in the EMR in conjunction with the Clinical Informaticist
4. Subject Matter Expert - Person who is responsible for knowing the details of the workflows and being able to cite evidence-based practices
5. Tester - Person who tests the tool to "make sure it works as designed" before approval
6. Approver - Person/committee who reviews the purpose of the tool and testing data and approves the tool for use
7. Publisher - Person who publishes the tool, after approval, for use by your clinical staff
8. Educator/Implementor - Person who trains clinical staff on the tool - Educates them about how it's published (where to find it), and how to use it
9. Monitor - Person who monitors the success of the tool after it's implemented, and troubleshoots any problems.

II. IF YOU HAVE A NON-PHYSICIAN INFORMATICIST :

If your institution has an informaticist who is not a physician, you might have the roles filled as such - Take, for example, the implementation of an order set for your Hospitalist group :

1. Owner = Hospitalist Director
2. Builder/Informaticist = Your non-physician Informaticist who works with your Clinical IT Analyst to build draft of tools
3. Clinical IT Analyst = Person who works with the Informaticist to build draft of tools
4. Subject Matter Expert = Hospitalist Director
5. Tester = Informaticist + Hospitalist Director
6. Approver = (Your order set committee)
7. Publisher = Your Clinical IT Analyst (who publishes the draft by moving it from TEST to PROD environment)
8. Educator/Implementor = Hospitalist Director
9. Monitor = Hospitalist Director

This is a perfectly acceptable setup, but your Hospitalist Director may not have time to fill all of those roles successfully :

Ownership - Deciding this does not take long, but...
Subject Matter Expert - This can take many meetings to help explain the clincal workflows and evidence-based practices - And depending on how much your director works clinically, he/she may have trouble answering detailed workflow questions.
Tester - This can take many hours reviewing tools and workflows and making sure they meet standards for approval - Again, depending on how much your director works clinically, he/she may not be helpful in testing the tool.
Educator/Implementor - This can take many hours explaining to staff how to use the tool and where to find it (especially if it's a new tool or something complex)
Monitor - This can take many hours to review the effectiveness of the tool - Are the hospitalists using it? Are they using it successfully?

And in a modern medical practice, the changes are coming fast and furious - Every time QA, or an insurer, or a regulatory body say "Jump this high or you won't get paid" - You will need someone to update/maintain all of those tools :

All of the hospitalist order sets will need constant maintenance
All of the hospitalist documentation will need constant maintenance (forms, notes, checklists, flowsheets, etc.)
All of the fancy tools will need constant maintenance (clinical pathways, protocols, etc.)

Every time the FDA makes a change - You will need to maintain all of these tools.

It's a lot for a modern clinical director to manage.

III. ENTER THE PHYSICIAN INFORMATICIST (AKA "EMBEDDED INFORMATICIST" OR "CLINICAL JEDI")

The physician informaticist works with the Department Director to help save time and continously maintain the clinical tools for the department, to keep up with the myriad of evidence/regulatory/billing needs. By training a hospitalist physician in informatics practices, you can develop the following arrangement :

1. Owner = Hospitalist Director

2. Builder/Informaticist = Your physician informaticist

3. Clinical IT Analyst = Your person who works with the physician informaticist to build a draft of tools in TEST environment

4. Subject Matter Expert = Your physician informaticist

5. Tester = Your physician informaticist

6. Approver = Your (order set committee)

7. Publisher = Your Clinical IT Analyst

8. Educator/Implementor = Your physician informaticist

9. Monitor = Your physician informaticist

So in this way, your physician informaticist will play all of these roles :

Builder/Informaticist
Subject Matter Expert
Tester
Educator/Implementor
Monitor

ANOTHER OPTION :

You *could* ask your Hospitalist Director to fill these roles, but you will have to pay him/her the salary for this time - Which, as Hospitalist Director ($250k/year?) is probably higher than the physician informaticist ($200k/year?)

ANOTHER OPTION :

If you have a non-physician informaticist, you *could* divide the roles this way :

Builder/Informaticist = Your non-physician informaticist
Subject Matter Expert = Your hospitalist director
Tester = Your hospitalist director
Educator/Implementor = Your hospitalist director
Monitor = Your hospitalist director

But again, this will mean :

Having to hire a non-physician informaticist (This could be $50k/year for maintenance.)
Having to pay your hospitalist director for the extra time it takes to fill all of those roles properly (Even at 0.1 FTE spent on that, that could be $25k/year for maintenance.)

The physician informaticist, by combining so many roles, saves a tremendous amount of time and money, and I believe you will have better maintained/updated/used tools.

By having a hospitalist trained in informatics, he/she can spend 0.8 FTE clinically, and 0.2 FTE on maintaining informatics for the hospitalist group and accomplish most of the maintenance very well, at a cost of about $40k/year for maintenance.

This then sets up the following structure :

1. Hospitalist Director = Makes all of the big decisions about "how things will be run"

2. Hospitalist Informaticist (aka "Physician Informaticist", "Embedded Informaticist", or my personal favorite, "Clinical Jedi") = Helps make Director's dreams a reality and worries about the details to implement them properly and quickly.

In this way, the Physician Informaticist becomes an essential tool of change. And because the tools are built by a hospitalist, buy-in problems are virtually eliminated.

So the next time QA says "Every hospitalist patient will need _________", the Hospitalist Director can work with his/her Hospitalist Informaticist, and relax knowing the details will be worked out, the tool will be rapidly changed, and the implementation will run smoothly.

IV. IN CONCLUSION

For all of these reasons, I believe the "Physician Informaticist" :

saves both time and money
improves change-management
improves departmental accountability (by having an expert in the department managing changes)
improves quality
improves reimbursements

... and so, I see this as a rapidly growing role in modern medicine, especially in hospitals who are going EMR or have gone EMR.

Would love to hear any thoughts/comments! Feel free to leave your experiences with physician informaticists!

What is a Procedure?

2011-04-03T23:33:00.007-04:00

For my fellow informaticists, struggling to explain both "why it's more complicated than it seems" and "Still, it doesn't need to be complicated"... I present : The Procedure.

The procedure is the workhorse of the Informatics Toolbelt. It's the hammer. Or the electric screwdriver. (In food terms, I suppose it would be the meat-and-potatoes, or the rice-and-beans - depending on your taste.) :)

The procedure is often the secret key to good informatics work products. It's often unloved, and misunderstood, but you'd be surprised how often I've been asked to "write a protocol" that actually turns out to be a procedure, or series of procedures.

When people talk about "mapping out the workflow", the procedure is often the starting point, the basic building block, and generally sets the framework for the rest of your workflow map.

When trying to map out a workflow, I generally recommend starting with the procedure. Most of the time, you will identify the other tools you need just by starting with the procedure(s).

By working out the procedure correctly, you can learn a lot about the safety before the procedure is ever implemented. In this way, well-written procedures can help reduce risk and create clarity.

I. BACKGROUND

A procedure is a detailed series of steps that should be taken to accomplish a defined goal. It's the clear list of instructions.

It should not be confused with a protocol. Protocols contain the conditional (IF/THEN) statements that allow a nurse, pharmacist, or other licensed health professional to start, modify, or stop an order on behalf of the protocol. Protocols are generally turned on/off with a physician order.
It should not be confused with a policy. Policies are stated goals/standards for the organization. While some procedures are paired with policies ("Policies and Procedures"), the policy is only necessary if you wish to "mandate" use of the procedure. If a procedure is not paired with a policy, it is optional. If a procedure is paired with a policy, then it should be a standard of the organization.

For this reason, procedures are sometimes published :

With a policy - ("Policies and Procedures") - When use of the procedure is a "mandated organizational norm"
Without a policy (e.g. Nursing Procedure Manuals, commonly found on most patient floors) - When use of the procedure is an option

II. DESIGN / CATEGORIZATION

Procedures should be written with clarity, simplicity, and with the end-user in mind. They should carefully balance specificity and ambiguity. Because procedures should communicate "how to achieve the goal", the steps should generally be numbered in order.

For best practice, it is helpful if each line of a procedure generally follows this format :

[ who ] will [ what ] [when] [where]

Where :

[ who ] is the person who will perform that step in the procedure, generally best described by job title

[ what ] is the exact activity the person will perform

[ when] is the time they will do it (e.g. "Until hands are wet" or "After patient is comfortable")

[ where ] is the location they will do it (if needed to clarify the procedure)

For example, one might write a procedure for washing hands :

Employee will approach sink
Employee will turn on water at sink until water is warm to touch
Employee will rub hands under warm water for 10 seconds
Employee will dispense 10mL of liquid soap into hands
Employee will rub hands together vigorously for 30 seconds
Employee will run hands under warm water for 20 seconds
Employee will turn off sink with elbows
Employee will dry hands with paper towel from paper towel dispenser
Employee will throw paper towel in garbage

This, of course, can be reformatted for simplicity as :

A. Employee will :

approach sink
turn on warm water
rub hands under warm water for 10 seconds
dispense 10 mL of liquid soap into hands
rub hands together vigorously for 30 seconds
run hands under warm water for 20 seconds
turn off sink with elbows
dry hands with paper towel from paper towel dispenser
throw paper towel in garbage

You will notice in the above examples that there are no "IF/THEN" statements. These are best kept to protocols, especially if the procedure involves a nurse/pharmacist/other licensed medical professional starting, modifying, or stopping an order on behalf of the physician.

Remember, that when writing a procedure, one should keep in mind : What will you use the procedure for?

Procedures can easily be converted into "instructions" for patients to use (e.g. if you want a patient to learn how to donate blood)
Procedures can easily be paired with "Policies" to mandate a particular way of doing things (in this way they help standardize care)
Procedures can be left alone, and published in a lone "Procedure Manual", to help your staff understand the best way to accomplish a particular goal.

It should also be asked : Do I need to write this procedure? As you can imagine, once you understand how to write a procedure, it can become tempting to write procedures for everything your organization does. I recommend you only write procedures when there is a :

Clear need to standardize a process (so you probably want to pair it with a policy)
Clear need to educate a process, but don't need it to be mandatory (in which case you probably want to publish it in a lone procedure manual or as a "set of instructions")

Finally, remember that many procedures can be quite complex. If there are multiple team members involved in accomplishing a particular goal, the "who" in each line should be clearly stated, preferrably by job title. For example :

Attending Physician will place order "Consult Gastroenterology" in patient's chart.
Attending Physician will contact GI Consultant to arrange for evaluation and consultation.
GI Consultant will evaluate patient
GI Consultant will order "Milk of Magnesia 30mL PO x1 dose STAT" in patient's chart.
Floor Nurse will give Milk of Magnesia as ordered

III. OWNERSHIP

Procedures will, like most clinical tools, require monitoring and upkeep. In general, they should be re-reviewed every 2-3 years, or more frequently if needed. For this reason, I recommend that procedures are owned by a clinical or administrative director who has been assigned to monitor and update the procedure as needed.

IV. CONSTRUCTION

It is recommended that procedures be written by someone experienced or trained at writing procedures (e.g. an experienced policy writer, informaticist or other specially-trained person), in conjunction with a subject matter expert.

Because the goal of a procedure is to communicate "how", they should use simple language that an end-user can easily understand.

First, a draft procedure should be constructed by the informaticist and the subject matter expert.

V. TESTING

The draft procedure should then be tested, in a testing environment, using at least one fictitious but realistic scenario and at least one representative from each job title found in the procedure.

After testing has been completed, the builder/policy writer/informaticist should examine the needs for the procedure, and decide whether :

The procedure should be paired with a policy and published in a policy and procedure manual
The procedure should be published in a lone procedure manual.

VI. APPROVAL

After testing has been completed, and decisions have been made (as to whether it needs a policy), the procedure should be brought to a committee for approval.

The committee should examine the goals of the procedure, testing results for the procedure, and the publication plan for the procedure :

Will it be paired with a policy?
Will it be published as a lone procedure?
Does it need to be converted to more patient-friendly "instructions"?

If the approval committee feels the procedure is evidence-based, well-tested, and safe, it should be brought to a vote.

If the approval committee votes to approve, then the procedure may be published for clinical use.

Please note : Some procedures (including many nursing procedure manuals, e.g. Lippincott) have subject matter experts and editors who thoroughly examine/test/vet/approve the procedures for use before publication. These procedures may generally be assumed to have been approved for use by the Lippincott editors, but your organizational standards may vary.

VII. PUBLICATION

After approval by committee, procedures should be published immediately :

In a Policy and Procedure Manual - For those procedures paired with policies
In a Procedure Manual - (e.g. Nursing Procedure Manuals kept in many clinical areas) - For those lone procedures which do not require policy mandates

Both of these manuals should be kept in the open, in a common place, where all end-users can easily find and review them.

VIII. EDUCATION

After publication, it is helpful if clinical staff is made aware of the publication of the procedure. Emails, posters, staff meetings, and sometimes classroom instruction can be helpful in educating staff about a procedure.

If the procedure is kept in a common, easily-accessible place, the procedure will require less education effort to be effective.

IX. MONITORING

After implementation/education of a procedure, it should be monitored for effectiveness and safety by the owner.

X. CITATIONS

http://www1.ucsc.edu/ppmanual/pdf/guide.pdf - UC Santa Cruz document about policy and procedure writing, and why policies, procedures, and guidelines should all be kept separate

http://en.wikipedia.org/wiki/Policies_and_procedures - Wikipedia article on Policy and Procedure - Please note the distinction between "Procedures" and "Policies and Procedures". (I also recommend some additions to their "standard template".)

http://www.bizmanualz.com/information/2007/11/12/why-do-you-need-to-write-procedures.html - Good piece about managing risk using well-written procedures

**My absolute favorite : Writing Effective Policies and Procedures : A Step-by-step Resource for Clear Communication by Nancy J. Campbell, AMACOM publishing, 1998. (If you buy one book this year, to help you do this - I recommend this one.)

Hope this was helpful! Would love comments, or your own stories about writing procedures!

What is an Order Set?

2011-03-25T19:38:00.006-04:00

It's funny. When I first got involved with electronic medical records at the Albany VA Hospital, as a resident, I remember one of their informatics people telling me, "You have no idea how political order sets are. The arguments I have seen over whether to check or uncheck a box... It's unbelievable."

She was right.

After you go electronic, prepare for the political discussions about order sets. Lots of people have opinions, but not many are actually are involved with building, testing, or development of order sets or using them.

So I thought I'd present this primer, to help people understand - "It's not just a bunch of orders with boxes." :

What is an Order Set?

I. BACKGROUND

An order set is a grouping of orders, used to standardize and expedite the ordering process for a common clinical scenario.

Before an order set can be created, the goal of the order set must be clear. Any necessary orders, contained in the order set, must be built first. (Order sets for new or innovative workflows should first be examined for any new orders that need to be engineered first.)

Order sets should only contain orders. They should not be confused with :

PROTOCOLS - Conditional IF/THEN statements, allowing a nurse/pharmacist/other licensed medical professional to start/modify/stop orders on behalf of a protocol, to automate and standardize the care for a common clinical scenario.
CLINICAL PATHWAYS - Tools used to standardize the discussion and goals of therapy, during rounds, for a common clinical diagnosis.
CHECKLISTS - Documentation tools used to document, standardize, and expedite the screening process for a common clinical scenario.
POLICIES - Agreed-upon standards for your organization
PROCEDURES - Detailed steps about how to achieve a desired standard.
PATIENT EDUCATION MODULES - Documents that help educate a patient about a particular subject (e.g. diet, disease, procedure, or aftercare)
STAFF EDUCATION MODULES - Documents that help educate a staff member about a particular subject (e.g. diet, disease, procedure, or aftercare)
DOCUMENTATION - Tools that help record and transmit patient history, condition, activities, responses, laboratory values, radiology images, and notes
GUIDELINES - Educational tools to help educate a staffmember about a general clinical objective (more flexible and negotiable than a policy)

For maximum safety, order sets should be built :

With clarity and a standard layout (Please see the ISMP Guidelines).
With all necessary information required to safely complete the order set.
With only those automating features which are absolutely necessary. (Risks/benefits of pre-checking orders must be closely examined on each order. As a general recommendation, pre-checking orders should be avoided on medication orders.)
With evidence-based practices.
To reduce variation and unintentional oversight.
To prompt for all necessary information.

Order sets can range widely in complexity, from very simple convenience order sets, to very complex order sets used to trigger clinical pathways or protocols.

II. DESIGN / CATEGORIZATION

Order sets typically fall into one of two primary categories :

Charge Order Sets - Those used by nurses and other clinical staff to create charges for common clinical materials (e.g. gauze, dressings, etc.)
Physician Order Sets - Those used by physicians to standardize and expedite the ordering process for a common clinical scenario.

Physician Order Sets may vary widely in complexity, but typically come in one of several types :

Admission Order Sets - (Sometimes called "Venue-specific order sets") - Used to admit a patient to a particular venue/service.
Diagnosis Order Sets - Used to standardize and expedite care orders for a common clinical diagnosis.
Convenience Order Sets - Used to standardize and expedite orders for a common clinical goal (e.g. a procedure, screening a patient, etc.

More complex physician order sets may fall outside one of these categories.

III. OWNERSHIP

Order sets are typically owned by a defined clinical director.

IV. CONSTRUCTION

Order sets should generally be constructed by a person trained/experienced in building order sets (e.g. clinical informaticist) in conjunction with a Subject Matter Expert (SME) and a Clinical IT Analyst.

V. TESTING

Order sets should be tested by all parties involved in the use and function of the order set. Generally, at a minimum :

One end-user physician should be able to understand and complete the order set
One end-user nurse should be able to understand and complete the orders from the order set

Additional users (e.g. Pharmacists, respiratory therapists, etc.) may be necessary for testing, depending on the type, complexity and goal of the order set.

Testing needs shall be determined by the clinical Informaticist in conjunction with the chairperson of the Order Set Committee.

VI. APPROVAL

After testing is completed, the order set may be brought to a committee for approval. The chairperson of the Order Set Committee will put the order set on the agenda, and allow a period of comments from voting members before the order set is brought to a vote.

Voting will be conducted by the Order Set Committee Chairperson.

If the order set is approved by committee, the chairperson will forward the order set to the Clinical Analysts for publication.

In the event of a tie vote, the order set will be brought to the Medical Executive President for further discussion or placement on the Medical Executive Committee.

VII. PUBLICATION

After approval by committee, the order set will be published for use :

An electronic version will be published in the EMR Order Set Catalog.
A paper version will be published into the Emergency Downtime Order Set Folder
An electronic version will be published in the Printshop Order Set Catalog, for creation of any paper order sets needed for remaining paper functions.

VIII. EDUCATION

After publication, staff education on the existence, goal, and use of the order set is the responsibility of the owner.

It is helpful if users are made aware of order sets, how to use them, changes, and reasons for change.

IX. MONITORING

After publication, all order sets will be monitored by their owner.

X. CITATIONS

ISMP's Guidelines for Standard Order Sets : http://www.ismp.org/tools/guidelines/StandardOrderSets.pdf

How to Install an Informatics Policy Framework, and Why?

2011-03-15T23:41:00.005-04:00

A common question I get asked is :

Q: "Dirk... We have over 600 different order sets... Now we can't save money on formulary costs, because the doctors still keep ordering the old antibiotics on the old order sets. What can I do?"

The answer is simply : You need to define your standards. By defining a standard way in which your order sets will be built, you can do a lot to "clean up the order set catalog".

STEP 1 : You will need to decide : Should we let doctors make their own order sets?

Pros : Less work to build order sets, and docs can build exactly what they want.

Cons : Less organizational control over standardizing care, less control over costs, higher maintenance costs.

If you decide 'we want to standardize our order sets', proceed to Step 2.

STEP 2 : You will need to convince your medical staff of the need for such standards. Create the following policy, then bring it to your medical executive committee for approval as a "General Clinical Policy". This will allow you to have a chapter of informatics policies in your clinical policy manual, and then start building a number of informatics policies to fill that chapter.

POLICY NAME : Chapter of Informatics Policies

POLICY : "All patients at Acme Hospital will be cared for with clinical information tools developed according to policies outlined in the chapter of Clinical Informatics Policies."

DEFINITIONS :

Clinical Tools - Any documents or other tools used to guide the delivery of clinical care. These may include, but are not limited to : Policies, Procedures, Orders, Order Sets, Protocols, Documentation/Forms, Templates, Patient Education Modules, Staff Education Modules, Charters, Schedules, and Minutes.

PROCEDURE :

A. Staff will consult the chapter of Clinical Informatics Policies prior to the construction of any clinical tool.

B. Staff may ask the Director of Clinical Informatics for guidance if any questions arise regarding the construction of these tools.

If you've designed this correctly, and your medical staff understands the issues, this should generate some discussion before it gets approved.

STEP 3 : You will then need a committee to help approve the policies that go in that chapter of Clinical Informatics Policies. Develop a committee charter, and bring it to your medical staff for approval.

Charter : Clinical Informatics Committee

Meeting Frequency : Monthly

Jurisdiction : Reports to Medical Executive Committee

Purpose/Task : To approve Clinical Informatics Policies on behalf of the Medical Executive Committee

Quorum : 50%

Voting Structure : By majority

Chairperson : The CMIO

Voting Members : ___________, ___________, ____________, _____________

If you can't get this committee approved by your Medical Executive Committee, then you will need to bring all Clinical Informatics Policies to the MEC for approval.

STEP 4 : Come up with a standard policy definition for an order set.

"An order set is a grouping of orders used to expedite and standardize the ordering process for a common clinical scenario."

or...

"An order set is a document with a group of orders, used to expedite and standardize the ordering process for a common clinical scenario."

or even better yet...

"An order set is a document with a group of orders, with evidence-based links, that is used to expedite and standardize the ordering process for a common clinical scenario. All orders on an order set are started, modified, and stopped by a licensed physician."

Any of the above definitions should suffice, depending on your need for clarity.

STEP 5 : Use that definition to write your first good informatics policy, in your chapter of informatics policies, to standardize your order set development.

POLICY NAME : Order Set Development Policy

POLICY : "All order sets will be built according to the procedure outlined below."

DEFINITIONS :

Order Set - A document with a group of orders, with evidence-based links, that is used to expedite and standardize the ordering process for a common clinical scenario.

PROCEDURE :

A. Order sets will be owned by a Clinical Director.

B. Order sets will be designed by an Informaticist and a Clinical IT Analyst.

C. Order sets will be tested by the Clinical Director and Informaticist and subject matter expert, using at least (1) doctor and (1) nurse, in a testing environment.

D. Order sets will be presented by the Informaticist to the Chairperson of the Order Set Committee for placement on the Order Set Committee Agenda.

E. Order set creation, change, and deletion will be approved by the Order Set Committee at the next available meeting.

F. Order sets will be published in the Order Set Catalog in the Electronic Medical Record.

G. Order sets will be monitored by the Owner (Clinical Director).

STEP 6 : Bring the policy you wrote in Step 5 to your Clinical Informatics Committee (so they can approve it on behalf of your Medical Executive Committee), OR if you can't get your Med Exec to approve the committee charter, bring the policy to the Med Exec for approval.

Voila! If you were successful, you should now have :

A chapter of Clinical Informatics Policies, in your clinical policy manual, that has been approved by your Medical Executive Staff.
A charter giving authority to a Clinical Informatics Committee to approve Informatics Policies on behalf of the MEC.
Your first Clinical Informatics Policy outlining the steps required to build, test, approve, and publish a standardized, evidence-based order set.
Your first meaningful change management mechanism for implementing electronic decision support and clinical workflows.

Once you have this rudimentary framework in place, you can then start working on updating the old 600 or more order sets. And if your order set committee is multidisciplinary and well-balanced, you can get balanced input before the order set goes live.

And your Informatics Committee can nimbly continue to develop informatics standards/policies that govern all of your clinical tool development.

This then brings you to Step 7 :

- Bring any old order sets to your order set committee for consideration of speedy deletion from your catalog.

- Build any new order sets according to the standard procedures outlined in the Order Set Development Policy (outlined above).

(You will probably need to tweak/format these policies to meet your organization's needs.)

I hope this was educational! Would love to hear how other folks handled their Informatics Policy framework! Remember, my advice is free, and as always, you get what you pay for. :)

What exactly is a Policy and a Procedure?

2011-03-10T00:22:00.003-05:00

Got back from the HIMSS11 conference in Orlando. First, a few quick impressions :

It was BIG. Lots of vendors, lots of people. Everyone selling you "a solution". With this many vendors, it's almost impossible to find a standard. Lots of portable toys, but no clear agreements about what's going to run on those toys. Looks like the industry has a ways to go before being mature, and HITECH has made lots of people "get into the Health IT business".
No meaningful standards yet. The discussion on the PCAST report was particularly interesting, as people debated .CCR, .CCD, HL7, and other standards that either "didn't meet payor needs" or "didn't meet physician needs" or "didn't meet software needs". As the guy behind SpeakFlower.org, I can tell you nobody was addressing a standard that meets patient needs.
The cabs and food were expensive. Taking a cab anywhere was $30 or more. Remember this the next time you book a hotel away from the convention center.
Lots of interesting people. Got into a robust debate with some tech and social media leaders about HITECH. My opinion : HITECH is going to drive small practices/hospitals to merge with larger practices/hospitals. Got into an interesting evening debate with some of those tech leaders, who seemed pretty blase and felt that was a necessary part of healthcare reform. Still, it underscores my belief that HITECH is about much more than just "let's get the docs to use computers".

Overall, definitely worth attending once, but remember - virtually everything at the conference is paid for with healthcare dollars. (If you want to save healthcare dollars, consider eating PB&J instead of a fancy dinner.) :)

Anyway, also at HIMSS, I spoke with several other informatics leaders who seemed puzzled by IT/Informatics governance, and how it relates to overall hospital governance.

To help, I thought I'd reinforce this basic informatics concept the same way I explained "What is Medicine Reconciliation, anyway?" -

So our lessons, for tonight, are "What exactly is a Policy?", "How is it different than a Procedure?", and finally, "What's the best way to make a policy / procedure?"

1. What exactly is a Policy?

A policy is a written goal of standardization for your organization. (E.g. "All patients will get low-salt meals." - The goal is to get low-salt meals to all of your patients.). It explains the who, what, when, where, and sometimes why.

A procedure is then the written steps it takes to get to that goal (E.g. "Step 1: Call kitchen Step 2 : Order low-salt meal Step 3 : Wait for meal to arrive") A procedure explains the how.

Both the policy and the associated procedure are generally kept on the same paper or electronic document, so that your employees can find and read those documents, and if they are written well, they will quickly understand :
- What is the standard/goal of your organization?
- How can he/she achieve this goal?

Writing a good policy statement is not easy. The focus has to be clarity. Short and sweet. In general, it shouldn't be more than one sentence - If it is, it's a warning sign that you may not have a clear goal.

A common mistake is to try to write several different policies into one policy - While it's tempting to do that to help avoid excessive committee discussion, putting several policies into one usually results in a policy that is unclear and ineffective.

So, some examples of unclear policy statements might be :

"Acme Hospital strives to provide low-salt meals which are nutritious and served warm and only to patients who need them. This is to meet the needs of the American Heart Association guidelines and other evidence-based recommendations. All employees will reinforce this rule."
"Acme hospital, to meet consumer demand, will make free parking available for any OB/GYN patients who are discharged."
"Wiping feet before entering the hospital has been shown to save floor cleaning costs. Floor mats will be used by all employees before entering the hospital."

Their corresponding improvements would be :

"All CHF patients will receive low-salt meals."
"All OB/GYN patients will receive free parking vouchers on discharge."
"All employees will wipe their feet before entering the hospital."

Remember, the trick to writing a policy statement is clarity. To do this, you will need to know :

Who/what does the standard apply to?
What is the standard?

By defining both of these, you can use the following template to write a good policy statement :

"[who/what does the standard apply to?] will [what is the standard?]"

And so you should only write a policy when :

1. You have a need to standardize something, and

2. You have the resources to enact and enforce the policy. (Just writing a good policy is not enough!)

Writing good policy requires proper balance between specificity and ambiguity. If you do it well, you will create clarity, and your policy manual will become a meaningful change management mechanism.

(I recommend "Writing Effective Policies and Procedures" by Nancy J. Campbell as a reference - It's really well-written and clear and provides ample education about how to write a good policy.)

2. How is it different from a Procedure?

If the policy is the goal, then the procedure is the steps it takes to get to the goal.

So, if we use the three policy statements we improved up above :

"All CHF patients will receive low-salt meals."
"All OB/GYN patients will receive free parking vouchers on discharge."
"All employees will wipe their feet before entering the hospital."

... then we can write clear procedures to achieve those goals :

Policy : "All CHF patients will receive low-salt meals."

Procedure :

Physicians will identify all patients with a CHF diagnosis on admission.
Physicians will communicate the full name/MRNO of all patients with CHF to the nurse.
Nurses will send the name/MRNO of all CHF patients to the kitchen with an order for a low-sodium meal.
Patients will wait for meal to arrive.

Policy : "All OB/GYN patients will receive free parking vouchers on discharge."

Procedure :

Discharge Planners in OB/GYN department will place a free parking voucher in all discharge packets.
Nurses in OB/GYN department will review free parking voucher with all patients on discharge.
Patients in OB/GYN department who have not received a free parking vouchers will be provided one on request.

Policy : "All employees will wipe their feet before entering the hospital."

Procedure :

Maintenance staff will maintain a mat at the entrance to the hospital.
All employees, before entering, will stand on the mat and wipe their feet for 10 seconds before entering the hospital.
After wiping their feet, employees may enter the hospital.

Obviously, writing real policies will be more complicated, as you work to address the myriad of clinical, regulatory, and organizational challenges that you will face in running a modern hospital.

The first pitfall about procedures is knowing the difference between :

A procedure kept in a policy document ("How do you achieve the goal?")
A procedure kept in a procedure manual (usually a nursing procedure manual, kept on most floors to help nurses review the best way to perform a particular procedure.)

If you're really fastidious, you can reference the procedure manual from your policy documents, so that you don't have to write the procedure over again (E.g. "Procedure to insert Foley : See procedure manual page 23 on 'Inserting Foleys'")

The problem with this approach is that while it may save you some time, you will still need to maintain both the procedure manual as well as your policy documents.

Another common pitfall of procedures is the "complicated procedure" where you have a bunch of complex, logical and conditional arguments, like :

Policy : Nurses will maintain blood sugars between 60 and 200 for all diabetic patients.

Procedure :

Nurse will check patient's fingerstick every 2 hours
If fingerstick < 60 then nurse will give 1 amp D50 IV and call physician
If fingerstick = 200 - 249 then nurse will give Insulin 2 units SQ
If fingerstick = 250 - 299 then nurse will give Insulin 4 units SQ
If fingerstick = 300 - 349 then nurse will give Insulin 6 units SQ
If patient becomes dizzy, nurse may call a rapid response.
Fingersticks may be checked more often for patients who feel dizzy.
If a nurse checks more than 4 fingersticks in a 2 hour period, nurses should call MD.

There are a few problems with writing this type of procedure :

It doesn't have a good "trigger" that makes a nurse start to follow these instructions.
It has a lot of "IF/THEN" statements.
It also has a lot of orders in it ("give Insulin 4 units IV" requires an order to be placed in your EMR.)

These are all giveaways that this is not really a procedure, but a protocol. (Remember, a protocol is a series of instructions and well-defined conditions that allow a nurse/pharmacist to start/modify/stop an order on behalf of the protocol.)

So the way to clean this up is to make a procedure that says this :

Policy : Nurses will maintain blood sugars between 60 and 200 for all diabetic patients.

Procedure :

Physicians with diabetic patients will place an order for "Diabetic Protocol" in the EMR.
Physicians will verbally notify the nurse that an order for "Diabetic Protocol" has been entered.

This then lets you make a Diabetic Protocol :

Nurse will check patient's fingerstick every 2 hours and as needed
If fingerstick < 60 then nurse will give 1 amp D50 IV and call physician
If fingerstick = 200 - 249 then nurse will give Insulin 2 units SQ
If fingerstick = 250 - 299 then nurse will give Insulin 4 units SQ
If fingerstick = 300 - 349 then nurse will give Insulin 6 units SQ
If a nurse checks more than 4 fingersticks in a 2 hour period, nurses will page MD
Nurses will check patients mentation every 2 hours
If patient becomes dizzy, nurse will dial operator to call a rapid response.

3. What's the best way to make a policy / procedure?

The funny thing is, most people aren't aware of the cognitive processes behind their daily activities. For example, you've probably sent lots of emails, right?

You probably didn't think about the steps you took to send an email :

You owned the email - Your brain decided, "I need an email to accomplish a goal."
You built the email - You actually typed the text of the email
You tested the email - You looked at it to see whether it was fit to send
You approved the email - Your brain felt the email was good enough to accomplish the goal
You published the email - Your finger clicked the mouse on the "SEND" buttom
You monitored the email - You waited to see the effectiveness of the email - If no response, you will probably repeat at step #2

So writing a good policy requires the same steps : Ownership, construction/building, testing, approval, publication, and monitoring. Let's just quickly review these before we wrap up for tonight :

Policy Ownership - If the point of a policy is to set a goal/standard, and your leadership/directors are the ones setting and enforcing the goals/standards, then it makes sense for policies to be owned by a director/leader.
Policy construction/building - This can be someone with training in building policies. (At a minimum, they should read the book I mentioned above, or attend some classes in policy writing so they can help the owner have clear and effective policies.) Informaticists are generally pretty good at understanding the construction issues, but you may choose to have someone special just to write your policies.
Policy vetting / testing / reviewing - Before bringing the policy to a committee for approval, you may need to "vet" or "appraise, verify, or check for accuracy" the policy. Who you bring it to, before approval, should depend on the committee chairperson for the committee you are seeking to approve the policy.
Policy Approval - This generally should be done by a committee with expertise in approving the policies. (If the policy has been properly vetted, there should be little discussion at the approval committee.) The committee chairperson should put the policy on the agenda, and at the meeting conduct a vote for approval for the policy. If the committee approves, the chairperson should sign the policy to show committee approval.
Policy Publication - After approval, this generally should be done by putting the signed policy into a policy manual, and then surrounding the arrival with some education to staff about the new policy.
Policy monitoring - This generally should be done by the owner, so if there is a change/update that is needed, they can go back to step #2.

It is for these reasons, then, that I put on my propeller-hat and recommend the following headings for your policy documents (these are not standard, but I would use them if I were to design a policy manual):

ORGANIZATION NAME

POLICY TITLE
CREATION DATE

I. PURPOSE :
II. POLICY STATEMENT :
III. SCOPE :
IV. DEFINITIONS :
V. PROCEDURE :
VI. OWNER :
VII. BUILDER :
VIII. CITATIONS : (This will help keep your policy manual evidence-based!)
IX. TESTED/VETTED BY :
X. APPROVAL COMMITTEE :
XI. APPROVAL DATE : (with chairperson signature)
XII. REVISION HISTORY :

Not everyone will have these headers, but if you're at the point of actually starting a policy manual, I think this could be really helpful in getting your organization to better understand these policy development, implementation, and maintenance issues.

Remember : My advice is free, and you get what you pay for. :)

(In all seriousness, this is how I might set up my policy headers and development process, but your mileage may vary.)

Would love to hear your thoughts/opinions! Please comment or ask questions - I would love to discuss other healthcare informatics issues! :)

The Policy that will realign your hospital's tires

2011-02-02T02:08:00.004-05:00

So I've been writing a lot recently about governance, and policy manuals, and how these are poorly understood mainly because nobody writes an instruction manual for a hospital. (That is, of course, with the exception of this blog.) :)

I figured I'd give insight, tonight, by giving you the clinical policy that will lay out the framework to :

Realign your governance
Re-engage your committees and physicians
Improve communication
Streamline policy development

So if your Policy Manual is your "sacred text" whereby your hospital operates...

And if your :
1. Clinical policies - Refer to patients and patient care issues
2. Administrative policies - Refer to employees and employee/hospital issues

Then you will want a Clinical Policy #1 that lays out your clinical policy manual, and an Administrative Policy #1 that lays out your administrative policy manual.

So for tonight, I present : The DRAFT CLINICAL POLICY #1 that will inject your hospital with new life. Look at it, and feel free to comment! Let me know what you think. (Remember, this is for education / discussion only - Your mileage may vary, and remember, with any free discussion - You get what you pay for!) :)

DRAFT VERSION - CLINICAL POLICY #1

I. Purpose : To outline the organization, development, publication, implementation, and monitoring of clinical policies at Acme Hospital

II. Policy Statement : All clinical policies at Acme Hospital will be owned, designed, formatted, tested, approved, published, implemented, and updated according to the procedures outlined in this document.

III. Scope : This document applies to all clinical policies at Acme Hospital.

IV. Definitions :

Policy - A written goal for the organization. Policy statements should be short and succinct, and written in clear, concise, and simple language.
Procedure - The detailed outline of steps staff members should take to achieve the policy goal. Procedures should be written with the user in mind, and should be developed by users.
Clinical Tools - Documents and other tools which are used to guide the delivery of safe and effective patient care. These may include, but are not limited to clinical policies, procedures, documentation, order sets, protocols, guidelines/pathways, templates, staff schedules, patient education modules, staff education modules, clinical committee minutes, and committee charters.
Clinical Policy Coordinator - The person responsible for the overall functioning of the clinical policy mechanism at Acme Hospital.
Chairperson of Medical Executive Committee - Traditionally, this is the President of the Medical Staff.
Owner - The person responsible for the timely review, updating, and dissemination of policies and procedures.
Builder [Informaticist, if your hospital is that progressive] - A trained person responsible for the design and testing of clinical tools before they are brought to a committee for approval.
Testing - The phase of policy development where a policy is checked for accuracy, safety, and reviewed by at least two end users before being brought to a committee for approval.
Approval Committee - A committee with the delegated authority to approve clinical policies, as designated by the Medical Executive Committee through a committee charter approved by the Medical Executive Committee.
Approval Committee Chairperson - The chairperson responsible for conducting meetings of an approval committee.
Publication - The process by which a clinical policy is published in a common clinical policy manual.
Implementation - The process by which a clinical policy is educated to front-line staff and enforced by directors and managers.
Monitoring - The process by which the owner continuously monitors the effectiveness and safety of a clinical policy.

V. Procedure : All clinical policies will be :

Owned : By a department director assigned by the Chairperson of the Medical Executive Committee.
Built : By an assigned builder [informaticist], assigned by the Clinical Policy Coordinator.
Formatted : According to the format outlined in Attachment A : Format of a Clinical Policy.
Tested : By the assigned builder [informaticist] and the owner, before presentation at an approval committee, using at least two front-line clinical staff members provided by the owner.
Presented : Shall be presented by the builder and owner to an approval committee assigned by the clinical policy coordinator.
Reviewed : Shall be reviewed by the assigned approval committee.
Approved : If a motion is raised to approve the tool for use, and the motion is approved, the approval committee chairperson shall document a vote of approval by signing the clinical policy during the meeting. In the event of a tie vote, or if the committee chairperson feels the policy has been incorrectly assigned, the policy may be referred back to the MEC president and Clinical Policy Coordinator for reassignment.
Published : In a common policy manual organized by chapters outlined in Attachment B : Organization of the Clinical Policy Manual.
Implemented : By the assigned builder [informaticist] and owner.
Monitored : By the owner

VI. Owner : President of the Medical Staff

VII. Builder : Chief Medical Informatics Officer

VIII. Tested by :

Regulatory Affairs, December, 2010

Senior Leadership, December, 2010

Chief Nursing Officer, December 2010

Chief Medical Officer, December 2010

IX. Keywords : Clinical Policy Manual, Clinical Policy, Administrative Policy, Owner, Builder, Testing, Approval, Approval Committee, Chairperson, Medical Executive Committee, Publication, Implementation, Monitoring

X. Approval Committee :

Medical Executive Committee, January 2011

XI. Approval Date :

Approval Body Chairperson : _________________________________________________

Chairperson, Medical Executive Committee Date

President, Medical Staff

Effective Date : ____/____/_____

Reapproved : ____/_____/_____

Attachment A : Format of a Clinical Policy :

1. All clinical policies should contain the following headings :

I. Purpose

II. Policy Statement

III. Scope

IV. Definitions

V. Procedure

VI. Owner :

VII. Builder :

VIII. Tested by :

IX. Keywords :

X. Approval Committee :

XI. Approval Date :

2. Should be formatted on 8.5" x 11"

3. Should be clearly labeled "CLINICAL POLICY - ACME HOSPITAL"

Attachment B : Format of the Clinical Policy Manual :

The clinical Policy Manual will be organized into the following sections and chapters :

1. SECTION I : HOSPITAL-WIDE CLINCIAL POLICIES

a. Chapter 1 : General Clinical Policies (Approved by Medical Executive Committee)

b. Chapter 2 : Nursing Policies (Approved by Nursing Committee)

c. Chapter 3 : Infection Control Policies (Approved by Infection Control Committee)

d. Chapter 4 : Laboratory Policies (Approved by Laboratory Committee)

e. Chapter 5 : Pharmacy Policies (Approved by P&T Committee)

f. Chapter 6 : Radiology Policies (Approved by Radiology Committee)

g. Chapter 7 : HIM/Informatics Policies (Approved by HIM/Informatics Committee)

2. SECTION II : DEPARTMENT-SPECIFIC CLINICAL POLICIES

a. Chapter 1 : Medicine (Approved by Medicine Committee)

b. Chapter 2 : Surgery / OR (Approved by Surgery Committee)

c. Chapter 3 : Pediatrics/Neonatal (Approved by Pediatric/Neonatal Committee)

d. Chapter 4 : Labor and Delivery (Approved by L&D Committee)

e. Chapter 5 : Behavioral Health (Approved by Behavioral Health Committee)

f. Chapter 6 : Pediatrics / Neonatal (Approved by Pediatric Committee)
g. Chapter 7 : Critical Care (Approved by Critical Care Committee)

Now remember, your hospital's Clinical Policy #1 may vary.

To provide proper oversight, then, the President of your Medical Executive Committee should meet with all of these chairpersons on a regular basis (once every few weeks/months) to talk about the health of the policy mechanism and any issues which arise. If the committee minutes, from all of these committee meetings, are published in a central location - The minutes will then also help communicate the overall state of affairs on your front line to senior leaders. (In this way, your policy mechanism becomes a tool of organizational communication.)

Anyway... One of the first questions you'll get, after you examine this draft, is, "What about my policies?", for example, Quality Assurance might argue "We need QA policies that help guide the enforcement of error reporting...!"

Your Medical Staff President and Clinical Policy Coordinator will have two options, when faced with this argument from various places in your hospital :

1. Create a new chapter in your policy manual for QA policies (in this case, probably under hospital-wide clinical policies) :
BENEFITS :

- QA will have their own chapter in the policy manual

- They can approve QA policies without discussion at the Medical Executive Committee

COSTS :

- You will need a new committee to approve the policies in this chapter

- You will need a charter delegating authority to that committee

- You will still need to oversee the subcommittee through regular meetings with the subcommittee chairperson.

2. Approve this sort of policy as a "General Clinical Policy" :

BENEFITS :

- Fewer committees needed to maintain this manual = Less staff needed to fill committees!

COSTS :

- Medical Executive Committee may spend time reviewing and approving many policies -

So : If Medical Executive Committee is spending too much time reviewing/approving QA policies, the Chairperson of the MEC should consider creating a QA subcommittee and approving a charter delegating that committee with the power to approve their own QA policies.

Would love to hear your feedback! Leave comments about your own Clinical Policy #1 stories! :)

The Financial Costs of Hidden Protocols : How Regulatory Bodies Can Help

2011-01-30T01:43:00.001-05:00

Know that very common tool known as the “Heparin protocol”? Whether your hospital is electronic, or paper-based, you probably have some version of it.

Take a good look at it. Is it titled “Heparin protocol”? Or “Heparin Order Set”?

Know the difference? Many people don’t. This is one of the hidden costs of healthcare that few people appreciate or understand.

A protocol is a document with a clear set of specific instructions, which allow a nurse, pharmacist, or other licensed medical professional to activate, modify, or discontinue a patient care order on behalf of the protocol. Any conditional (IF/THEN) statements should refer to well-described, discrete data elements. Protocols must be activated and deactivated by a physician order. Clinical protocols are commonly published internally in either an electronic or paper protocol manual.

An order set is a grouping of patient care orders (medication orders and other orders) to help expedite the ordering process for a common clinical scenario. Order sets are commonly published internally in either a paper printshop/order set catalog or an electronic medical record.

The problem is : Many hospitals confuse the definitions for these terms, and as a result, they engineer and publish protocols incorrectly. Instead of being published as protocols, they get designed, approved, and published as order sets.

Now look again at your order set. Are there any conditions that would make a nurse enter a new order, modify an existing order, or discontinue an order? “Discharge patient when criteria are met”, “This order should only be used in the ___”, “Advance diet as tolerated”, “If pain is uncontrolled, titrate IV to …” – Do you see any of those? If so, you may have protocols hidden in your order set.

Why is this a problem? Because protocols and order sets have different functionality, which brings unique engineering needs :

Order sets - Contain orders that are activated/modified/deactivated by a physician.
Protocols - Contain orders that are activated/modified/deactivated by a nurse/pharmacist. (based on a well-defined condition.)

The problem doesn’t just stop there. Protocols are sometimes confused with clinical policies.

A clinical policy is a written goal for a defined patient population. The clinical policy applies to the defined patients, from the time of approval to the time of discontinuation, both executed by an order of the President of the Medical Staff or an appointed chairperson.

A procedure is a written list of explicit instructions about how to achieve a particular goal. Procedures related to policy goals are commonly attached to policy documents and published in a policy manual. Procedures related to other goals are commonly published internally in either a paper or electronic procedure manual.

Now look at your clinical policies. Do you have protocols hidden in your policies?

What does this confusion cost a healthcare institution?

When the common clinical tools are not well-defined in hospital policies and charters, they can be poorly engineered. Poorly engineered clinical tools may not create their desired impact. This makes change management very challenging.

The cost of this confusion, unfortunately, generally goes unnoticed until an EMR (Electronic Medical Record) ultimately forces a hospital to contend with these definitions. In a paper world, the clinical environment will generally continue to function, even if the borders between all of these are blurry. In an electronic world, most software is not as forgiving as paper – Order sets appear in one place electronically, protocols appear in another, and policies appear in yet another. These may all need to be re-engineered to work electronically. (This is one of the reasons why hospitals see a performance benefit after they "go electronic".)

To contend with the management of these tools, even on paper, hospitals often designate committees to help review, approve, publish, and implement these tools. But because there are no widely-accepted standard definitions for these tools, the policies and committee charters that refer to these tools may be vague.

The net result : A committee that works to create a protocol, that mistakenly gets published as a policy, may not have the desired impact on front-line patient care. When this happens, the administrative costs of managing these tools can skyrocket, and those committees can feel powerless to make change.

Why are there no widely-accepted standard definitions for these tools? Surprisingly, none of the common regulatory or standards organizations in American healthcare seem to publish nor endorse common definitions. So where did the above definitions come from? I wrote them.

As a result of this lack of definition, hospitals are forced to contend with these engineering issues individually. Some will navigate this easily. Others will not.

My recommendation would be for CMS and Joint Commission to announce the publication of standard policy definitions for these very common clinical tools. While some hospitals will initially contend with meeting the new definitions, the long-lasting efficiency to the American healthcare system will be enormous.

They are welcome to start with my definitions, which are free. (Remember, you get what you pay for.) :)

On the Importance of Policy Mechanisms and Governance

2011-01-25T23:05:00.006-05:00

Healthcare is going through change. Tremendous change.

Pay-for-performance, ACOs, EMRs, and a rapidly growing buffet table of regulatory bodies are forcing hospitals to adapt, and quickly. Hospitals and medical systems that can change quickly, adopt new standards, implement new tools, and provide low-cost, high-quality care will survive. Those that can't, won't.

So recently I've had several conversations with healthcare leaders who are looking for help making change. Some of the questions I've heard :

"What can I do to help us make change faster?"
"Why aren't our physicians (or committees) engaged?"
"What can I do to help improve communication?"
"What can I do to help standardize care in our organization?"
"What can I do to help us work together as a team?"
"What can I do to help us implement our Electronic Medical Record?"

Believe it or not, all of these questions are related by a thing called "hospital governance", and probably the most important tool for hospital governance is your policy manual.

Q : "Dirk, what is hospital governance? It sounds like a civics lesson, or something from Schoolhouse Rock."

Every organization, from Apple to IBM to small businesses to hospitals, have some form of governance - A set of tools to make decisions and take actions. Why? Someone has to make decisions, and then someone has to get work done. Unfortunately, organizing those people, who may have conflicting opinions, and getting them instead to work together can be challenging.

It's not enough to just have "talented staff". If your staff isn't working together the way you want them to, it might be a sign that you need to look at your governance structure.

So what is the biggest tool you have to govern yourself? Your policy manual. Unfortunately, the governance, policy manual, and policy mechanism of most hospitals is probably one of the least taught subjects in healthcare management.

Bear with me, I'm going to explain it in simple language. :)

Q : "So, Dirk, what's a policy? What's a procedure?"

A policy is a written goal of your organization. The procedure is the list of steps you take to achieve that goal.

Good policy statements are short and sweet and clear. (A really good reference for this is Writing Effective Policies and Procedures : A Step-by-Step Resource for Clear Communication, by Nancy J. Campbell, 1998). Policy statements should not be paragraphs long - One or two sentences maximum. They should be clear and confident, e.g. :

"All patients will get kosher meals..." or

"All ED patients will get screened for influenza..." or

"All pediatric patients will get weighed daily..." or

"All female patients over age 40 will be offered screening for..."

(You'll notice all of the above samples refer to subsets of patients, so they are all samples of clinical policies.) Good policy statements create clarity out of confusion, and help your staff understand your organizational goals.

The procedure, then, are the steps you take to achieve the goal stated in the policy, e.g. :

"All pediatric patients will be weighed using the following procedure :

1. Patient will stand on a digital scale

2. Nurse will read digital readout on scale

3. Nurse will document the patient's weight in the patient's chart."

If you're not used to writing policies, it pays to invest in someone with training and experience. A good policy writer is worth their weight in gold. It's part art, part language, part human behavior, part communication, and part understanding workflows enough to write a good policy. Good policy writers can help create clarity out of confusion, and save your organization lots of money.

And you'll know if you have a good policy because someone on your front-line staff can read it, clearly understand it, and feel educated by the policy.

When should you make a policy for something? Anytime your organization needs to standardize something.
   - Need everyone to get weighed on admission? Write a policy.
   - Need all patients over 50 to be given cancer screening? Write a policy.
   - Need all order sets to look the same? Write a policy.
   - Implementing a new tool that everyone will use the same way? Write a policy.

The danger, of course, in bad policies is that sometimes you can write too much. If you write too much, you can "paint yourself into a corner". This can be a problem when a regulatory body comes to look at your policies - In general, they look to make sure your policies reflect your practice. If you write too much, you can end up with policies that are too long, or that don't reflect your current practice, or that you have to keep amending/updating too frequently.

Again, this is why you should invest in someone trained in the art of policy writing, to help you write short, well-constructed, thoughtful, and clear policies.

Q : "Can you give me a good teaching example of a policy and procedure?"

Sure. My favorite teaching example is this one :

POLICY : All patients will get a cupcake on admission.

PROCEDURE :

Kitchen staff will bake 100 cupcakes daily.
Couriers will bring cupcakes to floors.
Nurses will hand patients a cupcake when they are admitted.

What I like about this teaching example is it shows the thought that needs to go into a good procedure -

It is a simple example which, while somewhat comical, people usually don't forget.
It shows which staff will play which role (this is very helpful when figuring out who should review a policy before it is approved)
"100 cupcakes" - It shows the thought that needs to go into writing an effective procedure. The trick : to include as much detail as is needed, and no more - (How many cupcakes will you need a day? How many admissions do you usually have?)

This simple, well-written policy then helps directors budget for the time of their employees, and finance people to budget for the materials needed to make this policy work.

Q : "So what about the policy manual?"

The policy manual, then, is your total collection of policies. It should be treated like a sacred text. A good policy manual isn't torture - It's a source of education and communication across your organization.

- Have new staff you need to train? Use your policy manual!
- Have old staff that you need to train? Use your policy manual!

- Have directors who need to know "what's happening on the front"? Use your policy manual!
- Have staff who need to know what the organization's rules/objectives are? Use your policy manual!

Q : "That seems pretty simple, is that it?"

Hardly.

Q : "What else do I need to know?"

Everything you do with those policies determines how your organization functions.

1. The way you organize your policies is important.

In a large organization, it's not enough to simply put all policies into one binder. You'll want to make a table of contents that guide your front-line staff to the policies they are looking for. Often, you'll want hospital-wide policies (apply to patients regardless of location), and department-specific policies (apply to patients in a specific location). And then you'll want to subdivide those chapters. (See my post about Policy Manuals Made Easy for an example of how you might divide your policy manual.)

2. The way you test your policies is important.

Before your policies are brought to a committee for approval, you'll want the policy writer to "test" them. That means, you'll want to know that the policy has been checked for accuracy, that the workflows are realistic, that the spelling has been checked, that the formatting is correct, that the proper stakeholders have been asked about the policy.

If you test your policies properly, before they are brought to a committee, there will be little discussion at your committee. Ever hear the statement, "Why are we discussing these details in the committee meeting?" The more time you spend in the "testing phase", the less discussion there will be in committee. I can't say enough about the importance of investing in testing, before a policy is brought to a committee for approval.

3. The way you approve your policies is important.

Depending on how you organize your policy manual, you will need a committee, or a group of committees, to approve your policies. A well-designed committee is small, efficient, and has a well-designed voting structure, run by a committee chairperson who understands basic rules of parliament and chairperson responsibilities. (For this, I recommend Robert's Rules of Order : Newly Revised - In Brief.)

If your committee has a well-designed charter (and voting structure), and is run by a chairperson who understands their responsibilities, the approval process will be efficient and the committee will make good decisions - ultimately they need to decide whether to approve, deny, or modify a policy.

And if you organize your committee structure properly, then subcommittees that struggle to approve a policy, or end up in a tie vote, should usually have a top-level committee that can discuss all of the policies that cause extensive discussion.

4. The way you publish your policies is important.

It's not enough to have well-written, approved policies in a binder in someone's desk or laptop. The policy manual has to be organized, comprehensive, and put in a place where everyone can access it.

Every employee should know where it is, and should be introduced to it when they are hired.

5. The way you enforce and monitor your policies is important.

It's not enough to have well-written, approved policies in an organized, common policy manual. Managers need to enforce policies. Sure, during emergencies, there may be exceptions/emergencies where your front-line staff violate a policy, but when that happens, the employee should document the reason and managers/directors should ask "Why?". If someone is repeatedly violating a policy, it either means the policy is not appropriate/realistic, not properly designed, or the employee may need educating. (In my opinion, violating a policy should never be an automatic black mark against the employee - It should make the manager pause to reflect on the reason for the violation.)

It's also not enough to just schedule a re-review of policies every 2-3 years. Enforcement and monitoring is a continuous, ongoing job, which hopefully your managers are doing continuously. Those managers should be well-connected to your policy mechanism, so they can respond appropriately.

Finally, I will leave you with this Top-10 list of overheard comments which suggest your policy/governance mechanism may not be working the way you want it to :

"Why aren't our committees (or physicians) more engaged?"
"I don't know how to make a change around here" or "We can't change anything."
"Why didn't they tell us they were doing that?" (or "They have no idea what we're doing.")
"Who the heck passed that policy?" (or "That policy makes no sense.")
"Where is the policy manual?"
"I didn't know I was supposed to do that."
"Why do we have so many order sets?" (or policies, or protocols, or forms...)
"Our committee just decided against that, why are people still doing it?"
"Why aren't the owners updating their policies?" (or, "These policies are so old.")
"What can we do to standardize care?"

The good news is that organizing a policy manual and mechanism, and fixing your governance, can be a great experience that draws your entire staff together and rallies the troops. Feel free to leave your own stories about policy mechanism and governance!

Order Set Development and Preparing for the Downtimes

2011-01-12T00:48:00.002-05:00

So as if order set development wasn't challenging enough, some people will ask :

"Dirk... So once you go electronic, you don't need paper anymore, right...?"

Well, here's the bad news. You will probably still need paper order sets.

"Huh...?"

Yep. It's true.

You will probably still need paper versions of all of your order sets, just in case your EMR / CPOE goes down.

I know it seems like a lot of work, but think about this :

After you develop electronic order sets, your doctors will come to rely on them.
The time they save using good order sets will increase their efficiency.
The good order sets you've built will help them standardize care.
This improved efficiency and improved standardization will, over time, allow you to make staffing changes.

The problem, however, will be : What happens when your EMR goes down?

Will your docs have order sets that accomplish the same goals as your electronic order sets?
Will your docs suddenly lose efficiency that they accomplished with those electronic order sets?
Will your docs be able to handle as many patients as they did with the electronic order sets?
If your docs rely on those order sets, and your computer is down... What paper order sets will they use?

So here's the message : It's good practice if you simultaneously develop matching paper and electronic order sets.

"But Dirk... it takes so much time to make an electronic order set... how do I make a matching paper order set?"

Some people, when confronted with this demand, will try this approach :

Have one team make the electronic order sets
Have some person, after the electronic order set is built, type out a matching paper order set.

This approach works, but I think a smoother approach is to develop an order set process that allows your informaticists to develop both paper and electronic order sets as part of the same process.

This gets us into a discussion about order set development.

After a hospital goes electronic, they generally try to use the same process they used before to make paper order sets. Unfortunately, because of the new demands an EMR brings :

Now - Will need both paper and electronic order sets developed at the same time
Now - Will need better engineering (e.g. order sets separated from protocols, etc.)
So... Will need informaticists to help engineer those changes
And... Will need Clinical IT Analysts to help build the work that the informaticists do

... Eventually, you start to realize : The old process doesn't meet the demands of an EMR.

So I generally recommend developing an order set change process.

The Order Set Change Process

Order sets are like any other clinical tool your hospital uses : You will need to define :

Who is the owner?
Who are the builders / project managers? (Generally, an Informaticist + Clinical IT Analyst)
What importance/priority does the order set/change have?
Who will assign this importance / triage changes?
Who will build the first draft?
Who will test the new order set / changes?
Who will review the testing results?
What education plan (if any) will you need?
What companion documentation (if any) will you need?
What implementation plan (if any) will you need?
What accompanying clinical policy (if any) will you need?
What committee will "approve" your order set, after testing?
Who will implement the order set and the implementation plan?

So if you need to build both a paper and electronic order set, at the end of this process, here are my recommendations :

A. Develop an order set "Change Request Form". You will need this to help understand the expectations and understanding of your owner. Typical questions you might ask include :

Date of order set request?
Owner of order set? (I generally recommend this be a department director)
Builder/Informaticist assigned to order set?
Request : ( ) new order set ( ) delete order set ( ) change order set
If requesting a change, what is the previous order set you wish to change? __________
What change are you requesting? (Please be specific) : ________________________
What companion documentation will you need? : _________________________
Will you need an education plan/curriculum for this change? : ____________________
Will you need an accompanying clinical policy to support this? : ___________________
Will you need a protocol to help support this order set? : __________________________
Will you need an implementation plan for this change? : _________________________
Priority of change : (1-5, 1=low, 5=high) : ___________
Expected date of completion : __________________

(Generally, at the bottom of this form, it's helpful to have signature lines that match the key, important parts of the process below, so you can help keep track of the process...)

B. Develop a process. You will then need a process where that change request form helps lead your process. A typical process might look like this : (I've highlighted the various characters, so you see how many people might be involved and the roles they play...)

Change Request Form is published throughout hospital (explain to docs/directors that all order set building/changes/deletions will be done according to this form)
Change Request Form is completed by owner, and brought to CMIO for triage.
CMIO and Clinical Analyst Project Manager review form and assign a priority and assign an informaticist and clinical analyst to work on the project.
Informaticist works with owner to define workflows.
Informaticist creates first paper draft of order set, using orders found in your electronic order library/EMR. (This helps make sure your paper version matches with your electronic order sets.)
Informaticist defines testing plan : What front-line clinical staff will be needed for testing?
Informaticist gives first paper draft to clinical analyst to build first electronic draft.
Informaticist helps prepare companion documentation (if needed)
Informaticist helps prepare clinical policy (if needed)
Informaticist helps prepare protocol (if needed)
Informaticist helps prepare education plan/curriculum (if needed)
Informaticist helps prepare monitoring plan (if needed)
Informaticist helps prepare implementation plan (if needed)
Informaticist and Owner execute testing plan - Using front-line staffmembers the owner makes sure show up for testing
CMIO and Informaticist review results of testing together, and review current versions of paper/electronic order sets, protocols, policies, companion documentation, education plan
If CMIO and Informaticist approve - Then proceed
CMIO puts paper/electronic order sets on agenda for Order Set Committee - Sends notification/drafts/links to committee members
Informaticist and Owner - Pass clinical policy through committee for approval
Informaticist and Owner - Pass documentation through committee for approval
Informaticist and Owner - Pass protocol through committee for approval
Order Set Committee meets to review both paper and electronic order sets
If Order Set Committee approves - Then proceed
CMIO sends notification of approval of final paper draft to printshop : Paper order set is coded and published (usually to a "red file cabinet" where you keep "order sets needed for electronic downtimes)
CMIO sends notification of approval of electronic version to clinical analyst : Electronic order set is coded and published (by your analyst moving from test-->live, usually via your EMR)
Informaticist and Owner conduct implementation plan
Informaticist and Owner conduct monitoring plan (if needed)
Owner : Continuously monitors order set after use
(Restart at step 1 if needed)

Yes, it's a lot of work. Seems monotonous and boring, but you will need to define a process for order set change management, or else you will end up with order sets that lack support, order sets nobody uses, order sets with no monitoring/involvement, and poor project management.

You'll notice that the Informaticist title up above appears in many steps in the process. This is why you'll want an informatics platform after you "go EMR". Clinical IT Analysts (sometimes mistakenly referred to as "programmers") actually play a much smaller role in implementation than most people think - They're mainly there during development, to make the technical changes and advise the informaticist on technical limitations. You'll also notice that order set owners, once you define this process, will become much more involved in the development, testing, implementation, and monitoring of their order sets.

Finally, you'll want a CMIO to help manage your informaticists, and help corral your doctors/directors into this new process.

And, if you engage in this sort of process, your informaticists will be building/approving simultaneous paper and electronic order sets :

... so you can have an electronic order set that helps expedite the electronic ordering process (CPOE) for a common clinical scenario...
... and at the same time, you'll have a matching paper order set that can be filed in an emergency file cabinet to be used during electronic downtimes.

Phew! As I said : With order sets, there are no shortcuts.

This is part of the culture that EMRs bring. My advice : Prepare for change. :)

Would love to hear other people's stories - of how you developed a streamlined change management process for your order sets - I look forward to feedback! :)

Policy Manuals Made Easy

2011-01-06T01:27:00.005-05:00

Hi folks. Happy new year! May 2011 be even better than 2010 was! :)

So I've been asked recently about where informatics policies should live, ideally, and I answered, "In the clinical policy manual."

That led to a follow-up question : "Dirk, what exactly is a clinical policy?"

This gets to the heart of a really interesting conversation about healthcare : The difference between a clinical policy and an administrative policy.

First, a word about policies in general.

Policies are probably one of the most misunderstood things in healthcare. Most doctors shudder when talk centers around, "We should make a policy for that" or "Do you know what the policy is for _______?".

A policy is a written, agreed-upon goal. (The "procedure", often attached to the same document, are the steps about how-to-get-to-that-goal.)

Policies, then, are your organization's written goals. That's why The Joint Commission asks about them, during inspections - They want to know how you organize, how you think, how you operate, etc. They also want to make sure the policies reflect the practices in your hospital.

Policies, if well-written, don't need to be painful. Policies help guide your staff behavior, they help communicate goals, and if they're well-written, they can also be used for training.

They also help protect your staff - Their activities are backed up by the organization's support for that behavior.

"Aha. So you were talking about maintaining policy manuals?"

That's right, I was. Thanks for reminding me. :)

So an interesting thing about healthcare, unlike private industries - We have two policy manuals, whereas most non-healthcare industries only have one.

"And what are those two policy manuals...?"

Interestingly, to maintain an average hospital, you need two general types of organizational control :

Clinical Policies - Those policies that refer to patients and patient care
Administrative Policies - Those policies that refer to employees and employee issues

Why do you need two? Well, an average healthcare organization is usually run by a Board of Trustees, who at some point made the decision, "We would like to run a hospital here."

To accomplish this, then, the Board usually needs :

A group of administrative people who are experts at running the hospital - Keeping it organized, hiring people, making sure supplies show up, paying the bills, setting up the budget, running the place, sending out bills to insurers, etc.
A group of clinical people who are experts at delivering patient care - Performing surgery, seeing patients, taking vitals, giving drugs, managing ventilators, etc.

And that's why most hospitals typically have two wings of government :

The Administrative Branch
The Clinical Branch

... and the policy manuals that are used to help run these two branches of government are :

The Administrative Policy Manual
The Clinical Policy Manual

"I see... So what else do I need to know?"

Well, to run an average hospital, then, you need to have both clinical and administrative policies that help guide your daily activities. The conflicts that sometimes arise, between these two branches of internal government, are sometimes very complicated - And, as a result, not every situation calls for a clear administrative or clinical policy.

"So how do I recognize an administrative policy from a clinical policy?"

An administrative policy statement usually refers to employees or employee issues, so they typically start with something like this :

"All employees at Acme Healthcare will..." or

"All physicians at Acme Healthcare will..." or

"All nurses at Acme Healthcare will..." or

"All ED staff at Acme Healthcare will..."

The collection of these administrative policies is typically kept in an administrative policy manual.

A clinical policy statement usually refers to patients or patient care issues, so they typically start with something like this :

"All patients at Acme Hospital will..." or

"All pediatric patients at Acme Hospital will..." or

"All ED patients at Acme Hospital will..." or

"All terminally ill patients at Acme Hospital will..."

The collection of these clinical policies is typically kept in a clinical policy manual.

"Aha. So how do you organize these policies, then?"

Every hospital has a slightly different way of organizing them, but I recommend a very simple system of organizing them :

1. Administrative Policy Manual

a. General Hospital-Wide Administrative Policies

- Human Resources

- Safety

- Information Management / Medical Records

- Quality Management

- (Other organizational administrative policies)

b. Department-specific Administrative Policies

- ED

- Medicine

- Surgery

- OB/GYN

- Pediatrics

- (etc..)

2. Clinical Policy Manual

a. General Hospital-Wide Clinical Policies

- General Clinical Policies

- Quality Management

- Nursing

- Medical Records / Informatics

- Laboratory

- Radiology

- Infection Control

- Dietary

b. Department-specific Clinical Policies

- Medicine

- Surgery / OR

- OB/GYN

- Pediatrics

- ICU

- (etc. etc.)

Again, as I said, every hospital does this a little differently, to address their different needs, but the general theme is that they are all generally clinical or administrative policies, and they generally either apply throughout the hospital or in a specific department or physical area.

"Dirk... That sounds like a lot of work, then!"

It is a lot of work. If every policy has to be approved by a person or committee, there's a lot of work that goes into maintaining these policy manuals. Many hospitals struggle with doing this efficiently.

The good news is that it doesn't have to be torture. By delegating each branch of policies to the right person/committee, you can divide up the work efficiently, for example :

1. Clinical Policies

a. Hospital-wide Clinical Policies

- General Clinical Policies = Approved by Medical Executive Committee

- Nursing Policies = Approved by Nursing Committee

- Medical Records / Informatics = Approved by Med Rec / Informatics committee

- Pharmacy Policies = Approved by P&T Committee

- Infection Control Policies = Approved by Infection Control Committee

b. Department-specific Clinical Policies

- Medicine - Approved by Medicine Committee

- Surgery / OR - Approved by OR/Surgery Committee

- ICU = Approved by Critical Care Committee

- Pediatrics = Approved by Pediatric Committee

You'll notice the theme : Every branch of clinical policies will either need a committee or a person, delegated to maintain and approve that particular chapter of the policy manual.

And you'll notice how much work it takes to maintain all of this. Every time a drug gets recalled, every time the government creates new billing standards, policies have to be adjusted and re-approved.

The good news, if you do this well, is that you can use the policy manual as an education tool :

- For new staff who are orienting to your hospital

- For existing staff who would like to quickly find out daily operations

Finally, an important part about maintaining all of these separate chapters is that even if you delegate the maintenance of these chapters to different committees, it's imperative that you publish all of these policies in the same place. (That means, that all "active policies" are kept in one common place, where everyone can look at them.) By keeping the entire manual (all chapters) in one place, it :

Helps avoid policy conflicts between different departments, and
Helps make the policy manual a tool of organization and education for your staff.

Again, as I've said before, my advice is free and you get what you pay for. Every hospital does this a little differently, but I hope I've communicated the major themes. Would love to hear your stories and thoughts about best ways to organize a clinical and administrative policy manual!

Find any document in your hospital in five clicks?

2010-12-14T12:35:00.003-05:00

It's December. The squirrels have gathered their nuts. The leaves have fallen. People are having their holiday parties. It's a time for reflection, as we anticipate the new year 2011 that lies ahead. Healthcare is changing faster than ever before, and those who want to survive, need to keep up.

I've spoken in previous blog posts about the tools we commonly use to deliver care in modern healthcare. So as I've been thinking about how to streamline organizational efficiency in healthcare, one of the major challenges most hospitals face is : How do we manage all of this information?

Some people will immediately look to IT for solutions, since we think of information as living inside a computer, but IT can only build a system as organized as you ask them to build. The problem is : If you had chaos before, making things electronic will only perpetutate the confusion.

(I've spoken to plenty of healthcare informatics types who complain about not being able to navigate their web sites, shared electronic folders that never get updated, and not having "intuitive" organization of their information.)

I find the comment, "We don't have intuitive organization of our information" particularly interesting. Everyone seems to have a different idea of what is intuitive.

All of this speaks to the need for standardization in healthcare, and education to support those standards. (Nobody teaches this stuff in medical school, nursing school, or pharmacy school.)

So I hope I've attracted your attention with the title of this blog. My proposal : We develop a standard "document tree" that can be used to organize virtually all of your hospital's information. (Except emails, of course, which generally are private and not shared.)

The Healthcare Informational Tree

So I thought about all of the common tools we use in healthcare (the CMIO's Checklist and the Informatics Toolbelt), and sorted them first by function and then by division (Clinical versus Administrative) - And this is what I got as a final list :

Telephone Numbers - Tools to contact a person
Emails, Screen Savers, and Posters - Tools to help send a short message
Schedules - Tools to show who is responsible at what date/time
Policies and Procedures - Tools to learn organizational standards and how to achieve them
Guidelines - Tools to help educate and guide staff towards a desirable outcome
Documentation - Tools to record and transmit information
Orders - Tools to document and transmit instructions to deliver care
Order sets - Tools to standardize and expedite the ordering process for a common clinical scenario
Clinical Protocols - Tools to standardize and automate a clinical process
Clinical Pathways - Tools to standardize care for a diagnosis throughout a hospitalization
Education Modules - Tools to help educate patients/staff
Templates - Tools to help make a document
Wikis - Tools to organize information / links for a department
Committee Charters - Tools to assign committee duties and responsibilities
Committee Minutes - Tools to record committee activities
Glossary of Terms - Tool used to learn definitions for common organizational terms

I believe that by using the above directory/tree hierarchy, you could arrange your tools on your intranet in a way that you can essentially find any document in your hospital in five clicks - Each link, from this main page, then divides up into clinical and administrative divisions, e.g. :

Clinical Templates = e.g. Admission H&P template, Procedure Note template, Transfer Summary template, etc.
Administrative Templates = e.g. Policy and Procedure template, employee evaluation template, etc.

Clinical Documentation = e.g. Admission H&P, Procedure Note, Transfer Summary, Vitals Flowsheet
Administrative Documentation = e.g. Employee Evaluation Form, Room Change Form, Maintenance Request Form

Clinical Policies = e.g. Pharmacy Policies, Infection Control Policies, Nursing Care Policies, etc.
Administrative Policies = e.g. Human Resources Policies, Safety Policies, etc.

The interesting thing about making such a tree is it shows you, pretty quickly, how much work you are actually doing in your hospital, how much it actually takes to run a hospital, and why you need people to worry about all of these tools.

It also can help you find your work products much quicker, and it interfaces nicely with the tools that you need to make a change in the clinical setting.

Adopting such a tree is not a small project, but it sure can tidy up your intranet homepage. It also helps reinforce informatics education by making almost everyone in your organization review the basic tools you use, and what they do, every time they look for something. By having centralized publishing, this also helps keep your intranet a "high-value" site that people will use to find things.

As someone who wants to see American healthcare be the best that it can be, I think it's an admirable goal. Those of us working to organize Health2.0 should be keeping this tree in mind as we develop our healthcare informatics policies.

Remember, my advice is free, and you get what you pay for. Your mileage may vary. :)

Would love to hear comments about potential additions/changes you would make to the tree at your organization! :)

What is Medicine Reconciliation, anyway?

2010-12-04T00:22:00.006-05:00

So recently I've been hearing and reading a lot about medicine reconciliation.

Medicine reconciliation is the safety practice that, it seems, The Joint Commission has recently announced they will set new expectations for.

A friend of mine, who went to an IHI conference last year, told me that on a wall full of posters of "problem subjects", the "Med Reconciliation poster" seemed to have the most hospitals reporting challenges.

So what is this Med Reconciliation thing, anyway?

Is it a mythical creature that people see, but nobody ever really gets a picture of?
Is it something that inspires poets and artists, because it's so intangible?
Is it something that we can even achieve?

Most practicing physicians learned in medical school that it's "good practice to rip up and re-write all the orders when a patient comes out of the OR". Most practicing physicians are also used to documenting the patient's home medication list in an admission H&P. The interesting thing : These are both different facets of the same med reconciliation picture.

So then, I think one of the biggest challenges in implementing "Med Reconciliation" is that it's so hard to nail down. What is it, exactly? Who does it? And how?

So I thought I'd share some answers.

WHAT IS MED RECONCILIATION?

I. THE PREMISE :
First, the premise is simple : It's all about safety.

Med reconciliation is built on the basic premise that a physician and a patient work best together, when they're with eachother. For the purposes of this discussion, I've lovingly decided to call the "place where they work with eachother" the "Patient Care Cubicle" (instead of the industry term, "Level of Care" which is a little confusing.).

The process is then pretty simple. To perform med reconciliation, a physician needs two separate documents :

The 'home medication list', to know what the patient is 'usually on'.
The 'active medication list', to know what the patient is 'currently on' while sitting in this "patient care cubicle".

And the steps for doing med reconciliation? A doctor should basically follow these four steps :

Look at the Patient
Look at the HomeMedList
Look at the CurrentMedList
Make a new CurrentMedList!

This allows a physician can make the decision : What meds does the patient need to be on right now.

So remember, the recipe for med reconciliation needs these four ingredients :

MED RECONCILIATION = [ Patient ] + [ Physician ] + [ HomeMedList ] + [ CurrentMedList ]

(While they are connected, remember - Med reconciliation is NOT the process of collecting the home med list - But you will need to collect the home med list before a doc can do med reconciliation.)

So... when does a physician actually do these four steps of "med reconciliation"? Optimally, it happens at two times :

When the patient appears in your cubicle (in hospital terms this is known as a "change in level of care")
When the patient has had some significant event (like delivering a baby, a code blue, a surgery, etc.)

So far, so good. Now comes the implementation challenges.

B. THE BASIC IMPLEMENTATION

The first thing you might do to map out the implementation of med reconciliation, is to make a general map of all of the "patient care cubicles" your patient might pass through, when he/she goes through your hospital. Typically, this map will start with the outpatient cubicle, and end with the outpatient cubicle. (On discharge, then, you need to do med reconciliation one last time to define the "new home med list", aka the "discharge medication list").

So if each "cubicle" has the patient and a physician :

The physician covering the "outpatient cubicle" is the primary care physician.
The physicians covering the other cubicles are the ones you assign.

And so if you need two lists - The home med list, and the current med list - To perform med reconciliation, you can see by the above slide that the first challenge will be getting the home med list available in your ED.

This brings us to some challenges with med reconciliation...

C. THE FOUR BIG CHALLENGES

The first challenge is just getting the home med list in your ED. How long does it take to actually assemble the list of home medications? (Remember : THIS IS NOT MED RECONCILIATION YET - Collecting this list is probably the thing most commonly confused with the term "med reconciliation".)

I did an informal study of this, while working clinically last year, and found that my median time for most adult medical inpatients was about 20 minutes. About 2/3 of my population was less than this, but about 1/3 of my patients were more than this, and there were some significant outliers - some patients took up to 45 minutes or more. (While slightly tongue-in-cheek, I called the standard I used the "mother standard", figuring I would work to achieve the same accuracy I would expect for my own mother.)

The reason it can take some time to assemble is this : There are up to seven data sources a person can use to assemble the home medication list. They include :

The patient - Who usually knows their home med list... but not always.
The family - Who is often helpful at establishing an accurate med list, but not always
The PCP - Who is usually accurate, as long as the office is open and they know what the specialist might be prescribing, so...
The specialist - Who sometimes needs to be contacted for clarification about new specialty medications
The outpatient pharmacist - Can be helpful to get a broad view, assuming the pharmacy is open and the patient doesn't use a mail-order pharmacy
The previous chart - Can also be helpful, assuming the last visit wasn't too long ago
The "insurance-based electronic prescription database", available at some hospitals - Which also still sometimes takes time to sort through, and you have to make certain assumptions...

So if the first step is to assemble this list in the ED, then the first challenge is to figure out who will assemble this list, and how?

Curiously, if you examine med reconciliation needs in the ED department, it usually falls along these steps :

Triage desk Officer : Generally drug classes are most important, not actual drug names. (E.g. a triage officer may consider bringing someone in if they are on blood thinners, or antibiotics.)
ED physicians : Generally drug names are most important, sometimes doses. Most ED visits are short, so there has not traditionally been much focus on doing med reconciliation in the ED. Of course, if we expect ED physicians to perform med reconciliation, they will need more information. (Some patients do miss medication doses while waiting for care in the ED.)
Inpatient Physicians : Here is where the drug, dose, route, frequency, indication, and last dose are most important, because the patient staying in-house will need to continue the right medications at the right times.

Because of these varying needs, at these different levels, it's sometimes hard to figure out who's responsible for how much of the puzzle.

The second challenge, assuming you can get the home med list assembled in the ED, is figuring out : Which physicians will be responsible for actually doing med reconciliation in each cubicle?

While it's tempting to answer :

ED - Would be performed by ED physicians, 24/7
Floor - Would be performed by hospitalist physicians, 24/7
ICU - Would be performed by intensive care physicians, 24/7
Etc...

...the PreOP setting/OR/PACU usually presents some unique challenges (challenge #3)

The challenge for many ORs/PACUs is this : Operating room schedules are tight. Hospitals count on maximum efficiency in an operating room. Even small delays can be magnified into cancelled procedures if everything doesn't run like clockwork. Also : Surgeons and anesthesiologists spend a good part of their day in procedures that simply can't be interrupted. Briefly pulling a hospitalist out of a family meeting to "do med reconciliation" will have a very different cost than briefly pulling a surgeon / anesthesiologist out of a surgery.

To accommodate with these demands, many anesthesiologists focus mainly on anesthesia meds, and many surgeons write post-operative orders in the PACU. If the patient goes up to the floor, after the PACU, then the nurses depend on the post-op orders written by the surgeons in the PACU. Unless you create a cubicle where the PACU has the same level of care as the floor, you might have to do med reconciliation again after the patient reaches the floor.

Figuring out this workflow can be very challenging. It's why my friend, going to the IHI conference last year, saw Med Reconciliation as one of the 'top challenges' hospitals face.

The fourth, and final challenge, is deciding on the "triggers" you will use for med reconciliation. As described above, there are typically two things that should trigger a physician to actually perform med reconciliation :

Patient arrives in your patient care cubicle (aka "Change in level of care") - This is usually pretty easy to enforce electronically.
Patient has a significant change in status (e.g. delivery, surgery, code blue) - This can only be enforced by a policy/clinical practice.

So you will need to decide on these two triggers, knowing that

For your EMR to trigger med reconciliation electronically, you will need to organize your levels of care and their relationship to your patient locations.
For your staff to trigger med reconciliation during a significant patient event, you will need good policy design and education.

D. THE NEXT STEPS / SOLUTIONS

Fear not, my reader! This may seem daunting, but the problem can be solved! Many hospitals have started down this pathway already, and many more will continue as The Joint Commission and other regulatory bodies reinforce med reconciliation practices.

To help you, I've offered the following recommendations and steps you can take to advance the discussion in your own hospital.

Define who is responsible for collecting the home med list in the ED
Define what home medication information they will collect, and how? (It's challenging to figure out how many of the seven potential data sources to use, but until our whole country is wired together electronically, your organization will need to decide this.)
Define where this home med list will be kept, once assembled, so that every doctor in the "chain of cubicles" will be able to access it and use it to perform and document "med reconciliation".
Define your "patient care cubicles", where your EMR can help trigger the med reconciliation process.
Define your policy that will help educate physicians about clinical scenarios in which you expect med reconciliation to be performed (e.g. delivery, code blue, surgery, etc.)
Define which physician's will be responsible for the med reconciliation process in each cubicle, 24/7.

Regarding the unique challenges that most Operating Rooms/PACUs present, this is a very common challenge, but I'll present the following possible scenarios I came up with :

Your hospital might consider asking the surgeons to perform med reconciliation after the patient arrives back up on the floor. (This may cost your hospital in OR time/efficiency.)
Your hospital might consider transferring all post-op patients to your hospitalist group, to allow the hospitalists to perform med reconciliation on the floor. (This may cost your hospital by needing more hospitalists to care for these patients.)
Your hospital might consider hiring a Physician's Assistant (PA) or Nurse Practitioner (NP) to assist the surgeons with the med reconciliation process. (This may also cost money, but I believe in most settings this would be more affordable than option #1 or #2 above.)

Enjoy - I hope this discussion has been helpful. A good sample policy to support med reconciliation is available here from the University of Wisconsin Hospital and Clinics. Again, I'm eager for any feedback folks have. Feel free to leave your own stories about tackling med reconciliation! :)

Converting paper order sets to electronic

2010-11-21T01:17:00.004-05:00

If you're reading this, I hope you're the person in your institution trying to "convert the paper order sets to electronic ones".

Don't worry - you're perfectly normal. The job is usually a lot harder than it looks. And no, you're not the only one who hears, "Why can't you just take the paper order sets and put them on the screen?"

(Most people think it's simple, until they actually start to dissect the order sets.)

First, let's start with some of the challenges of paper order sets :

Paper order sets generally keep multiplying - Let's say you decide to fix the paper order sets, and so you need to take the old versions "off the shelves". Beware - People tend to make copies of paper order sets. So the old ones can turn up weeks and months later.
Paper order sets are often engineered differently - In the electronic (CPOE) world, orders are very concrete. You may have specific safety features put into your electronic PCA (Patient-Controlled Anesthesia) order. How will you put those safety features into your paper order set? You may also have hidden "protocols" in your paper order sets. What will you do with those protocol (conditional) orders?
Paper order sets are sometimes ignored, after a hospital "goes electronic" - If you ignore your paper order sets, what will your hospital use during electronic downtimes? Can you afford not to have paper backup order sets, if your OR/ED are busy?

Believe it or not, how you address these paper-order-set problems will be vitally important in your long-term electronic success. Ignore the paper order sets, and you will miss an opportunity to really set up a robust electronic platform.

Let's look at each of these issues in a little more detail :

1. The "Multiplying paper order sets" -

This is a phenomenon many organizations struggle with. The solution : Centralize all of your order sets on one common electronic web site, and publish them as non-editable .PDF files. Create a clinical policy where "If it's not on this site, it's not an acceptable order set". It will take you a while to get the site together, and organize all of your paper order sets there, but in the end, you will have a way of controlling the paper order sets in use.

2. The "Engineering differences" between paper and electronic order sets

Some organizations, on going electronic, focus on developing electronic order sets, while the paper order sets continue to be produced in the way they "always have been built". If you have two separate processes (an electronic and a paper process), the problem is that you will start to have significant engineering differences between the two.

If you have different paper and electronic order sets, you will then encounter :

Paper order sets that don't meet the engineering standards needed for order entry in your EMR, so they will be very hard to "send-to-pharmacy-so-someone-else-can-do-the-order-entry"...
Paper order sets that don't match the electronic order sets
Two cultures : Docs who use electronic order sets, and docs who use paper order sets. (If your organization does a "flip-the-switch" approach to EMR/CPOE, then this won't apply to you. If you do a "gradual conversion", then this will apply to you.)

The way you fix this, of course, is to develop simultaneous paper and electronic order sets. Set up your informatics platform, update your policy on order set development (to include paper and electronic order sets), and ask your informaticists to develop the paper and electronic order sets simultaneously. Have them tested by the same people, and approved by the same committee. This will ensure that they match, and even if you are a "100% CPOE" organization, you will still appreciate having matching paper order sets during electronic downtimes.

Remember, the solution isn't to make electronic orders that mirror your bad paper processes. Make good, solid, and safe electronic orders, and then use those in your updated paper order sets.

A final tip : Embedded "protocol" (conditional) orders generally need to get pulled out of the paper order sets, before you can "make them electronic" - and you will need to decide what to do with those : A. publish them as new protocols, or B. throw them out. This will take work and can be politically challenging.

3. The "Ignored Paper Order Sets"

Some organizations, on going electronic, ignore the paper order sets, thinking, "We don't need them anymore, right?". My advice : Don't ignore them. Not only will you need to figure out what your pharmacy will do if they end up getting faxed paper orders, but you will still need them for computer downtimes.

If all of this sounds complicated, and it sounds like a lot of work, you're right - It is. This is why order sets are the political and organizational challenge that they are. A good informaticist can help sort out the issues and put a plan and process into place for your organization, where it doesn't have to be too painful. Unfortunately, because healthcare doesn't have standards in clinical processes, every organization handles this conversion differently, and as a result, order sets are notoriously hard to standardize. (Think of them as a "custom-fitted suit".)

One last tip : Beware the "quick fix" - There are consultants who will "easily and quickly convert your paper order sets to electronic ones". The way they usually do this is by taking the paper orders, no matter how they are engineered, and simply build new electronic orders that match them. In the short term, this may appear to work, but in the long term, it may leave the nurses with orders which are unclear (and may create extra pages to doctors to clarify), since some paper orders are not as well-defined as their electronic counterparts. You may also miss out on the opportunity to streamline your clinical processes, and miss out on the time and cost savings that an EMR can really bring. My recommendation : Build the new paper order sets to match the engineering standards of your electronic order sets - Not the other way around.

As always, my advice with order sets : There are no quick fixes. Hire a good informaticist to help you with this. :)

Hey, by the way, I'm open for questions - If anyone has any EMR conversion or informatics questions that you'd like to chat about, feel free to leave a comment here or email me. I'll try to devote my next posts to reader questions! So send me stories, questions, or whatever else you'd like to discuss in upcoming posts - I look forward to hearing from folks! :)

What's in the Informatics Toolbelt?

2010-11-06T02:35:00.001-04:00

QUESTION : Dirk... How do I make change in a clinical setting?

A lot of modern healthcare asks for standardization. Common questions I get asked are focused on change and standardization, such as:

"How can we make sure the doctors use the order sets?"
"How can we make sure the doctors document ______ properly?"
"How can we make sure the doctors enter orders for ventilator changes?"
"How can we make sure the nurses document the vitals properly?"
"How can we make sure the pharmacists document the medication substitutions properly?"

The first tool most people reach for, to standardize care, is the order set. As a result, order sets are notoriously political. In the paper world, they generated enough debate, but in the electronic world, it often gets worse, as the political power shifts from a physician-centered process to a more organization-wide process.

Question : Huh? Dirk? Electronic order sets have a different political structure than paper order sets?

The short answer is yes. Why?

In a paper order set, most hospitals let doctors type their commonly-used orders on a piece of paper, put little check boxes next to each order, and a committee reviewed them - if the group of orders looked safe and met the right formatting requirements, and didn't have any unapproved abbreviations, the order set was generally approved, and the doctors could use them. End of discussion, for the most part, until the order set had to be updated. The doctors wrote what they wanted, and the organization approved them as long as there wasn't any major safety or organizational problem.

In an electronic order set, every electronic order (in the order set) has to be built by a programmer. So quite often, those programmers design the orders with extensive safety in mind. To figure out how to make them safer and more effective, the programmers ask the entire team (not just the doctor) for advice on how the order should be built. So programmers may ask the pharmacists, "How can we make this order safer?". They may ask the respiratory therapists, "What should this order look like?". They might ask the nurses, "What should the doctors really be asking for in this order?". They might ask the dietitians, "What should a diet order look like?". They might even add evidence-based links to the orders, on the order sets, to help guide the physicians about when best to use which orders.

As a result of these discussions with all of these different parts of the hospital, it's not uncommon for the programmers to design the electronic orders to look and behave differently than the paper orders did.

For example, a common safety tool used by programmers, after these discussions, is to build mandatory fields into the orders, that the doctors have to complete for the order to be accepted. As a result, the doctors are suddenly forced to think differently about these electronic orders, than they used to think about the paper orders.

I know it's still still sort of complicated, but a good example of this phenomenon is the diet order.

In the paper world, most paper order sets simply refer to an order, "REGULAR DIET".
In the electronic world, however, after discussion with speech therapists and dietitians, many electronic diet orders are built with mandatory fields for texture and liquid modification, so a doctor HAS to think about texture and liquid modification just to be able to enter a diet order. As a result, many electronic diet orders, on an electronic order set, will refer to the diet order, "REGULAR DIET, NO TEXTURE MODIFICATION, NO LIQUID MODIFICATION".

So doctors moving from the paper world to the electronic world will generally sense this loss of control - Suddenly, dietitians and pharmacists and radiologists can have enormous impact on the way they order something. In the paper world, doctors could simply write whatever they felt was best.

As a natural result of this political shift, electronic order sets often generate even more political discussion and debate than the paper order sets did. And this is another reason you may want to hire a CMIO, to help guide your doctors past the political debates and focus on good patient care.

Question : Aha. Interesting... Never thought about that. So what about this "Informatics Toolbelt" you mentioned?

The reason I bring up the "Informatics toolbelt" is because, as a hospital tries to standardize care by crafting workflows, everyone seems to reflexively reach for one tool : The order sets. By fixing the order sets, we can standardize care, right?

While order sets are certainly a good tool to help standardize care, they are not the only tool. Just to remind you that there are other tools, I present the following list of tools which I think sit in the Informatics Toolbelt : (Remember, most of these tools can be published either on paper or electronically...)

An order - A medicolegal instruction to provide a defined portion of patient care, via a defined route, at a defined rate, for a defined period of time. (Remember, in the paper world, you didn't have to "build" orders - In the electronic world, you have to "build" them, so you can actually engineer them to your advantage - The source of much political debate.)
An order set - A grouping of orders, to help standardize and expedite the ordering process for a common clinical scenario. Physicians generally start, modify, and stop the orders on an order set.
A protocol - A document that allows a nurse or pharmacist to start, modify, or stop orders based on a well-defined clinical condition.
A guideline - (aka care plan, etc.) A document that educates care team members about desired outcomes and processes, but generally carry less medicolegal weight than a protocol or policy, more negotiable, so they are engineered differently.
A policy (clinical or administrative) - A defined organizational goal or rule.
A procedure - The steps requires to achieve a goal (or policy).
Documentation - (aka a forms, a flowsheet, etc.) - A permanent recording of patient status, activities, responses, and outcomes in time, authenticated by the signature of a licensed medical professional.
A patient education module - A document with media (written, video, or other) that explains a defined set of educational objectives to patients.
A staff education module - A document with material (written, video, or other) that explains a defined set of educational objectives to staff members.
A committee charter - By creating a charter, you can create a committee that helps standardize your care and monitor your processes
Committee minutes - By creating minutes, you can show effective supervision and committee activity to meet the organization's goals.
A staff meeting - Can be helpful for education and organizational purposes.
Email, paper mail - Can also be helpful for educational purposes.

There are probably other tools to put into the Informatics Toolbelt, but these are the most common ones. And a good informaticist can help you figure out the right mix of tools to craft the workflows you want to create to improve safety and standardize care.

(Using these tools to craft a workflow, in the electronic world, is an art known as electronic decision support. This is why a clinical informaticist is a key role in managing your clinical processes in the electronic world.)

Hope this helped remind you that order sets are a good tool to help craft a workflow and standardize care, but not the only tool. If you forget about the other tools, you may be missing out on other opportunities. A good clinical informaticist will help you figure out which tools to use for which scenarios. :)

A Few Words About Education in Healthcare and Life

2010-11-05T08:04:00.001-04:00

So I recently got a very nice email from a person at a healthcare informatics consulting company, asking me to participate in a webinar on healthcare informatics. Two pieces of the email that really made me smile :

"Your blog was sent to me by a colleague who found it extremely educational on the topic of medical informatics. I quickly agreed; you discuss what can be very complicated systems and the politics of implementing an EMR in terms a layperson such as myself can easily understand. It has become a great resource for our staff as we continue to learn and grow within the HIT community."

and

"We were very impressed by the information in your blogs along with your conversational style..."

So I'm thrilled that someone picked up on what I try to do - Educate in a painless, simple way that people actually enjoy. A great example of this style can be found in the NPR Radio Show This American Life, where every week Ira Glass and various other writers/readers tell stories that are actually very educational. On This American Life, they have recently tackled subjects as complicated as the economic meltdown, credit default swaps, and other hairy political, legal, and financial issues, all told through stories that people share about their lives.

A great example of painless education told through story is their show about the financial meltdown, called The Giant Pool of Money. This is a true educational masterpiece. Every sentence in the show show lures you in, grabs you, and explains world banking and finance in a way that is totally tangible and palpable by the masses. You leave the piece feeling full of amazement at what you just learned.

This is the style of education I try to emulate in healthcare informatics. There are a lot of discussions in healthcare that are full of drama and intrigue, worthy of a Shakespearean drama. I try to convey it that way. :) (Although admittedly, I don't have as much time, creativity, or talent to emulate the TAL writers.) :)

Anyway, this gets me to my subject of education in healthcare, and in life.

Education is not something that has to be painful. It just has to require work. The first step is approaching a subject with :

An open mind
Eagerness to learn
The humility to admit you might not understand something

If you can achieve that, then you will be a great student and will learn a great deal, in school and in life. As social human beings, I think it's our nature to be BOTH a teacher and a student, as long as we live, and we have that responsibility to play both roles to keep our society intact.

I think part of the educational problem is that people don't appreciate how much work it takes to make education painless. Good teachers are worth their weight in gold and platinum. We also think of education as ending after high school, or after college. Yes, we pay attention to higher education too, but there are many, many ways we educate eachother, as humans :

We go to grade school, high school, and college
We talk to our friends and neighbors
We watch eachother and watch our children play on a playground
We tell stories at family reunions
We ask questions (to learn and to teach!)
We scribble ideas on cocktail napkins
We create and watch movies and videos
We write and read books and web pages
We write and listen to songs.
We write laws and policies.

Although the law, and most discussion centers around #1 as an educational medium, there are many other ways to achieve an educational goal.

One of my favorite stories I collected during medical school was when my parasitology professor, Dr. Calum Macpherson, told us about his time spent fighting parasitic diseases in Africa. In one story, he described a particular disease, echinococcus, which was causing disabling and life threatening liver and abdominal cysts in animals and people in a particular region.

The challenge to him and his team, he reported, was preventing the behavior where people would feed pieces of these large, salty, abdominal cysts from dead animals to the dogs in the neighborhood. (Gruesome, perhaps, but when you have dead animals, and hungry dogs, it only makes sense.) This behavior, unfortunately, perpetuates the life cycle for the parasite, and the disease continues to spread.

So how to prevent the behavior of feeding these cysts to neighborhood dogs? One way: To educate the village. So they developed a creative solution. Working with local people, they created a children's song that could be performed and sung at a playground, during playtime. They made the song catchy enough that kids liked to sing it.

Apparently, many years later he went back, and still found the kids on the playground singing the song they wrote about "not feeding cysts to dogs".

A creative approach, and effective. Perhaps the first example of a viral idea.

In conclusion : Don't let education intimidate you. It takes work, but it doesn't have to be painful. :)

Why not let docs have their own order sets?

2010-10-25T00:10:00.002-04:00

Last week, I was asked a question I'd been asked many times before, by someone who was helping another hospital set up their EMR :

"Why shouldn't we let our docs make their own order sets?"

The reason I was asked this is because many EMR packages have this feature, where docs can make their own order sets for their own convenience.

REASONS TO LET DOCS MAKE THEIR OWN ORDER SETS :

Every doc struggles with efficiency, and making your own order sets certainly is tempting. Why not make order sets that accomplish exactly what you want? After all, if I'm a practicing physician, and I know what orders I 'always put in' in certain scenarios, why shouldn't I be able to make my own order sets?
We could save so much committee time if the docs could just make their own order sets!
If the docs could make their own order sets, they would probably feel "more comfortable" with order sets and CPOE, in general - Wouldn't this help us with our EMR implementation? Wouldn't we get a higher CPOE rate faster?
It would save the time and labor of converting their old paper order sets - (Which, as I've discussed in past postings, are often loaded with embedded protocols which are expensive and time-consuming to engineer out!) - Just let the doctors make their own order sets!
If docs could make their own order sets, then they probably wouldn't blame some poor informaticist for making a bad order set for them.

REASONS NOT TO LET DOCS MAKE THEIR OWN ORDER SETS :

If every doc can make their own order sets, you have no centralized mechanism for clinical decision support. For example, if your pharmacy previously paid a lot for omeprazole, and it suddenly gets a good deal on pantoprazole, you will probably want all of your doctors to take advantage of the cost savings by steering them towards pantoprazole (when backed by good evidence) - If they all have their own order sets, you won't be able to help guide physician behavior and take advantage of this cost savings.
If every doc can make their own order sets, you also have no centralized mechanism for standardizing care. E.g. an appendectomy could get very different care, depending on which physician was using which appendectomy order set. (Most hospital administrators are trying to standardize care to improve quality and reduce costs.)
Order sets need to be maintained regularly, to be kept safe, evidence-based, and efficient. If every doc can make their own order sets, you may quickly end up with many, many different order sets which can be a challenge to maintain, from a technical standpoint. What are you going to do when new guidelines suggest you should be using different drugs to treat pneumonia? How will you find which order sets you need to update? Do you have the resources to keep ALL of your order sets updated?
If every doc can make their own order sets, you will miss out on the opportunity to teach your physicians what informatics is, and how they can improve their own care through evidence-based practice and standardization of processes.

I will admit, as a practicing physician, myself, there are times where I wish I could just make my own order sets. But I will also admit that being challenged on my own order sets is a great learning experience, and ultimately, sharing the discussion with my colleagues, and reviewing the literature is the best learning experience of them all.

(Apparently I'm not the only one who frowns on personal order sets - A final web page, worth reading even though the author is unclear and this looks more like a comment than a legitimate argument :

http://www.informatics-review.com/wiki/index.php/Personal_Order_Sets)

Ultimately, every hospital will need to make this decision for themselves, but remember, as I said - With order sets, there are no free lunches. The rule still applies. :)