Thursday, December 22, 2011

Rethinking Prescription Writing Standards (SIG)

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 :
  1. QD - In Latin : Quaque Die - In English : means "Once a day"
  2. BID - In Latin : Bis In Die - In English : means "Twice a day"
  3. TID - In Latin : Ter In Die - In English : means "Three times a day"
  4. 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 :
  1. q2h = Every 2 hours
  2. q4h = Every 4 hours
  3. q6h = Every 6 hours
  4. q8h = Every 8 hours
  5. q12h = Every 12 hours
  6. q24h = Every 24 hours
  7. q48h = Every 48 hours
What I find interesting is the common question, "Should I write this medication QID or 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.
  1. QD = usually 08:00am
  2. BID = usually 08:00am and 20:00pm
  3. TID = usually 08:00am and 12:00noon and 20:00pm
  4. 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?


So today at work, I was rethinking the sig :

And it's interesting - I noticed that in about 90% of prescriptions :
  1. PRN (as needed) medications : Often use q____h PRN _________________
  2. 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?


It seems the real division is between regular (every day) medications and PRN (as needed) medications.
As I mentioned :
  2. 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!


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!

Wednesday, December 14, 2011

Van Halen and why Informatics is not IT

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.

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.

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.
  1. They tried spilling food in the middle of the restaurant. No go - Someone came and cleaned it up.
  2. They tried yelling really loud and carrying on. Didn't work. The workers called the police and they were escorted out.
  3. 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.

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! 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 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!

Friday, December 2, 2011

Rethinking electronic documentation filters

"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 :

  1. What and when to document - and...
  2. 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 :

  1. The timeframe you need (X-axis)
  2. 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 :

  1. 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.
  2. The ability to mark documentation with not only the author, but the profession/specialty they represent.
  3. 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! :)