Sunday, November 29, 2009

Embedded Informaticist Culture = Wave of future?

I'm going to use this moment to play "Healthcare IT Futurist".

ARRA/HITECH are here, and the ink is almost dried. You may be asking yourself : How am I going to get my hospital up-and-running on a new EMR? How can I make our EMR project succeed?

I've already written a bunch about the little-known secret : Clinical Informatics.

If you're serious about success, then you may be asking yourself the follow-up question : If Clinical Informatics is the answer, how do I get this into my hospital?

Let me tell you about the inspiration I used to solve this problem.

Get ready - It's modern, hip (perhaps too much), and most healthcare people are sort of shocked when I tell them the answer : Star Wars.

The original 1977 movie, written by George Lucas, has clearly been influential on me and most Generation Xers. It is firmly woven into the popular American culture. It's been parodied endlessly on YouTube, and for good reason : Parody is the sincerest form of flattery. Words like "Jedi" and "Yoda" have worked their way into the general American lexicon, and for good reason : George Lucas managed to work the power of myth into a really good story about human themes like good and evil and redemption.

Obviously, it struck a chord : According to Wikipedia, a 2007 AOL UK Money article estimated the six movies have netted over $4.6 billion worldwide as of 2008. (I'm trying to find the actual source of this estimate, but it seems most internet links refer to the Wikipedia quote : Please don't shoot the piano player.) Anyway, the exact amount is irrelevant. It was still a worldwide hit.

Anyway, you're probably wondering, "So why is this CMIO writing about his Star Wars inspiration?"

Yes, I am a fan, but what I want to do is give some insight into how the movie helped me to successfully develop an embedded informatics program.

First, a reminder on the tribal nature of medicine : On starting down the road to implementing your EMR, you'll be quickly reminded of how tribal medicine is :
  1. Doctor tribe (includes the sub-tribes : ED, Hospitalist, OB/GYN, Pediatrics, Surgery, etc.)
  2. Nurse tribe (also includes the sub-tribes : ED, Hospitalist, OB/GYN, Pediatrics, Surgery, etc.)
  3. Pharmacist tribe
  4. Dietitian tribe
  5. Other ancillary service tribes
To take care of your patients, each of these tribes does a unique dance with eachother. Often patient care starts in your ED, where a member of the ED Nurse tribe - The triage nurse - Starts the dance. The Triage Nurse then communicates with other ED staff, to continue this elaborate dance. Eventually, your ED Doctor and Nurse start to communicate with inpatient staff, often a Hospitalist and inpatient (med/surg) nurse.

So... When you get an EMR, you'll quickly see these tribes come into conflict with eachother, as you try to re-arrange things to work in the "electronic world".

Again, you're probably wondering : "Dirk, where are you going with this?"

Well, here's how this tribal conflict affects your EMR implementation : To successfully implement your EMR, your CPOE, and your order sets : You will need to know VERY, VERY well about how your tribe members do their dance. And you will need to be able to negotiate their tribal cultures to adapt to a new world.

In clinical language, that means, "You will need to play nicely with other groups and be able to describe what you do very clearly for the IT people, or else your EMR implementation is going to be rocky."

In management language, that means "You will need to know, communicate, and negotiate their workflows VERY, VERY well, or else your EMR implementation is going to be rocky."

In political language, that means "You will need to figure out who's going to make these highly technical decisions, and how these decisions will be accepted, or else your EMR implementation is going to be rocky."

In financial language, that means, "You'll have to budget for people to help analyze your workflows, or else your EMR implementation is going to be rocky." (In a past post, I wrote about how this is the "hidden cost" of EMR implementation that most vendors don't fully explain, and even when they do, most of us don't understand the message.)

Now I can hear you asking, "So Dirk, how does a Hollywood movie (Star Wars) help me implement my EMR?"

Before I give you the answer : Remember, when you start to tackle the enormity of the workflow analysis needed to support your EMR transition, that you're generally faced with two options :
  1. Hire an outside consultant to help solve the problems.
  2. Use your own staff to help solve the problems.
Hiring an outside consultant is often a good answer, because outside consultants will often know the strategies needed to successfully implement your EMR. If your hospital is completely new to the term "Clinical Informatics", and/or you don't have a CMIO, an outside consultant may actually be your better option.

The downside? They won't know your hospital culture. If you're lucky, they'll have some clinical experience, but ultimately they're not a member of any of your clinical tribes, so they will take time to learn the workflows. And that's going to cost you money as they learn.

So suppose you want to use your own staff...

The good parts of using your own staff (embedded informaticists):
  1. You can potentially find your own clinical tribe members who know your workflows.
  2. You can potentially harness them to help train your other clinical tribemembers (e.g. An ED doc making sure all ED docs know your ED doctor workflows, an ED nurse making sure all ED nurses know your ED Nursing workflows, etc.)
  3. You can potentially harness them to help your IT department develop systems which integrate well into your hospital.
  4. You can potentially harness them to develop decision support to increase your revenues.
  5. You can potentially harness them to perform CQI/Datamining for their clinical tribe.
  6. You can potentially harness them to help negotiate new workflows (e.g. If we have to re-do things to work in the new electronic world, how are we going to do it?)
The hard parts of using your own staff (embedded informaticists):
  1. Budgeting for their time to do this.
  2. Identifying "Who's the best person in each tribe to do this?"
  3. Training them to do this.
  4. Figuring out, "Once these embedded informaticists start to organize, how are we going to fit their highly technical opinions into the hospital hierarchy?"
So finally : Here's where George Lucas and Star Wars have provided me with enormous inspiration to solve this problem. (I highly recommend going out, buying the entire series, and watching it to review!) :)

When you watch the series, pay serious attention to the Jedi Knights that exist throughout all six Star Wars movies.

Loosely paraphrased from the Wikipedia page on Jedis, I bring to you the mythical Jedi code (for those of you who may not be big fans of the movies) :
  1. Jedi are the guardians of peace in the galaxy.
  2. Jedi use their powers to defend and protect, never to attack others.
  3. Jedi respect all life, in any form.
  4. Jedi serve others rather than rule over them, for the good of the galaxy.
  5. Jedi seek to improve themselves through knowledge and training.
In the interest of avoiding legal problems, I am certainly *not* advocating creating a new position in healthcare called "Clinical Jedi". At least, not unless you get George Lucas' blessing. And even then, prepare for your HR department to raise some ugly questions, like, "What is the going rate for a Jedi?" :)

But what you will find by watching the series : To adopt an embedded informatics culture in your hospital, you will essentially need to find the people in your hospital who follow this mythical Jedi code.

What I did, to develop our embedded informatics group, is make some modifications to the mythical Jedi code, to give it some real-world clinical practicality :

An embedded clinical informaticist :
  1. ... is a solid clinician who lives in the clinical world (generally at least 80% of the time)
  2. ... ultimately serves the patient, then their clinical tribe, then IT/hospital administration (in that order).
  3. ... is passionate about knowing their workflows.
  4. ... is politically neutral, like Switzerland.
  5. ... is intellectually pure, like behind the curtain of a voting booth.
  6. ... believes in the power of negotiation and education, rather than "brute-force" solutions.
  7. ... is "IT-friendly".
  8. ... can perform basic data-mining on your electronic clinical data, to help them understand the functioning of their clinical tribe, and thus become a better informaticist.
  9. ... works with administration to identify goals for improvement and help support those goals from an informatics perspective.
  10. ... works with their clinical tribe members on training, education, and workflow analysis.
Traditionally, informatics has been seen as something that's run in an office, or a small group. What's unique about an embedded clinical informaticist : This brings informatics right to the front line of your clinical care.

Culturally, this is like Gutenberg developing the printing press to spread the power of communication to everyone. Having an embedded informaticist in a clinical tribe will only help the functioning of that tribe.

I can only report that we have had tremendous success with following this model, and while I admit I am still struggling with budgeting and organizational issues (like most hospitals do, when they implement an EMR), I have quickly been able to identify about 25 clinical people who are willing to follow that code and fill this role, and we now have a mechanism to help bring clinical informatics to the front-line of clinical care.

This not only helps the stability of our EMR implementation, but it also helps improve communication and coordination between departments. Ultimately, this all helps to improve patient care.

So finally, before I end for tonight, I would like to thank George Lucas for using the power of myth to inspire a generation of leaders. Even those working in healthcare. :)

Wednesday, November 18, 2009

Lack of Informatics support in ARRA/HITECH

I recently had this discussion on, and thought it would make a good post.

The topic was about ARRA/HITECH (what else?), and I commented that I didn't think the country was ready from an informatics perspective. My evidence : The number of times doctors confuse q12h with BID.

(A simple experiment you can try yourself : Walk into your local pharmacy and ask the pharmacist how often they get scripts which confuse the two.)

Anyway, on, a consultant asked me :

"Hi Dirk--
I'm wondering if you could explain a bit more your statement: "The problem is teaching docs the difference between "BID" and "q12h"." Are you saying that docs need to be trained to know the terms are different, and when to use each, or are you saying they're essentially interchangeable, and structured documentation would benefit from uniformity and choosing one as the standard? Would like to hear more of your perspective, and how informatics should be implemented. "

... To which I replied :

So glad you asked! (Remember, my advice is free, and you get what you pay for!) :)

Anyway, "BID" and "q12h" - These are very, very different terms medically. Only problem is, they LOOK very similar.

BID essentially means "Twice a day", and q12h means "Every 12 hours".

Get the difference? If you're a little puzzled about the difference, you're perfectly normal. I can tell you a LOT of docs struggle with the difference too.

BID technically, as "Twice a day", means generally 8am and 8pm. (In some hospitals, it means 10am and 10pm). But in most hospitals it means 8am and 8pm.

So if you write "Give Flagyl 500mg PO BID", the nurses will give it at 8am and 8pm. If you write the order at 1am in the morning, the first dose will get given at 8am -- 7 hours from when you wrote the order.

"q12h" technically means "Every 12 hours" - So if you write "Give Flagyl 500mg PO q12h" at 1am in the morning, the first dose will generally be given soon (maybe 2am?), and the next dose will be 12 hours from now (2pm).

Unfortunately, a surprising number of doctors don't understand this basic tenet of prescribing drugs. We only find this out when we "go electronic" and suddenly some doctor comes with a complaint : "I wrote for Flagyl 500mg PO BID at 1am and the drug didn't get given until 8AM??!?!?!"

I'm the guy who sees all these problems. So I'm the doc who has to tell the other doc, "Uh, you know that there's a difference between the two, right?" And then I'm the doc who sees their face, and the inevitable follow-up comment : "Well, I always USED to write it like that, and we never had this kind of medication delay before...This system stinks!"

And then I'm the doc who sees the truth : In the past, docs would write this, and pharmacists and nurses would just *compensate* for what we're doing - "Oh, Dr.Acme wrote for Flagyl 500mg PO BID for that patient admitted with C.diff at 1am - Of course he meant it to start now, so we'll really change it to q12h!"

We can all look at this and say "Well if there is JCAHO-mandated medication verification in pharmacy, then the pharmacist should have changed Dr. ____'s order to q12h" - The problem is that most pharmacists are physically separated from the patients, and have no way of really knowing why the patient is being admitted - A *very astute* pharmacist might question "Why would they order an antibiotic at 1am to start at 8am?" and perhaps call for clarification before approving the order - But unfortunately, this requires a very astute pharmacist and a significant amount of extra steps.

So... "What we have here is a failure to communicate"... The doctor didn't really understand the difference between q12h and BID, and a medication delay resulted.

The doctor will usually blame the software, when it's really a basic medication ordering problem. The doctor will also usually say "This worked better on paper", and he/she is right, it did work better on paper, because we all used to have more wiggle room and flexibility, and a lot of nurses and pharmacists would compensate for the doctor's mistakes. (Ask any nurse or pharmacist about this phenomenon, I'm sure you'll hear lots of stories.)

So, yes, we can give away the technology, but there is a lot of learning and culture shift that needs to take place, or else the doctors won't be happy with the outcome of going electronic.

This is where Clinical Informatics comes in, and I've written about Jedi Informaticists in the past to help fill this role (see the AMIA 10x10 class which is a quick way to get a Clinician up to Jedi speed), but I don't see much talk about "How we're going to pay for the Informatics to support this technology" in the ARRA/HITECH bill. Nor do I see that we have enough Jedis to make this transition successfully.

By the way, your question : "Are you saying that docs need to be trained to know the terms are different, and when to use each..?" - Yes, that's exactly what I'm saying. My post above explains the difference between the two pretty well, I think. Now if you could just get every doctor in the country to read my post, that'd be great. :)

(Oh, and the next time there's some "clinical compensation" phenomenon we uncover, I'll have to explain that too - And if you could just get the docs to read my next post, that'd be great too.) :)

Unfortunately, informatics isn't taught in medical school. And they didn't need to teach it when hospitals were on paper - Everyone just compensated for the docs with regards to these things. Now we need embedded clinical informaticists ("Jedis") to help rescue this situation, or else these docs will forever be unhappy with the outcomes of "going electronic".

Sunday, November 15, 2009

Thinking EMR? Why you need a CMIO...

I'm trying out this post, for an article I'm writing for a magazine in the near future. Enjoy!

Looking at an EMR (Electronic Medical Record) for your hospital?

If you’re a hospital administrator with a pulse, you’ve probably heard about the HITECH (Health Information Technology for Economic and Clinical Health) Act, which promises money if you are using an EMR in a “meaningful way”. And if you don’t meet the government deadlines by 2015, you’ll start to feel the yearly “disincentives” of 1%, then 2%, then 3% cuts to your Medicare reimbursements.

You’ve also probably heard moans and groans from staff who are worried about the changes it’s going to bring.

Here’s the truth : You’re right to be worried. It does bring a lot of change. Stuff you’re probably not even thinking of yet.

You may have also heard about the failure rate of EMRs. Industry estimates vary widely, but in October 2007, Modern Healthcare polled their readers and found that 19% have gone through de-installation of their EMR. In addition, 30% responded that they either had, or currently have, an EMR that some docs simply refuse to use. (You can read their article here : )

So what do you to avoid problems and failure and medical errors?

The solution is something loosely called Informatics. And here’s why so many hospitals fall short with their EMR implementations – It’s because clinical informatics is so poorly understood.

Question : So what is clinical informatics? In language I can grasp?

Clinical informatics is tough to explain to most administrators. I won’t even give you the published definitions, because generally they make people’s eyes glass over.

What I can tell you is, it’s not IT. Informatics is a totally different creature. And you need to budget for it if you want your EMR implementation to succeed.

Informatics is the field where clinical care, technology, politics, finance, information science, education, evidence-based medicine, statistics, and policy intersect. It recognizes that technology is about 20% of the solution, and workflow is 80% of the solution.

Unfortunately, many in healthcare have the misconception that technology is going to be 80% of the solution.

When you plug in an EMR, some believe that the experience will be loosely similar to the experience of, say, putting the install disks for Microsoft Word into your computer - That you’ll install the software, and put the right data in the right places on the screen, and be happy with the output.

A modern hospital EMR is nothing like that experience. Thinking that the two are similar is setting up your EMR project for failure.

What you start to do, after plugging in an EMR, is ask questions : Who needs what data at what time? How am I going to train all of my staff to use the software? How am I going to train all of my physicians in CPOE? How am I going to train them in electronic documentation? How do I train my nurses to document meds and vitals properly? And, what am I going to do when someone needs to change something?

Informatics deals with these questions. Remember : 20% of the issue is the technology, 80% of the issue are the policies, procedures, and workflows you’ll need to understand to answer those questions.

You’ll soon find out that the paper order sets you worked so hard on, in the past, don’t seem to work in the electronic paradigm. At least, if they do, they usually require significant changes, and then require you to educate your clinicians about the new-way-of-doing-things.

And you’ll feel frustration when your clinical staff starts to ask, “Why do we need to do things differently now?”.

You’ll also start to find the holes in your current education system. If you thought your education staff had trouble just getting across basic hospital policies for regulatory issues – Prepare yourself to educate them on new software updates, new order sets, and new workflows. And every time the insurance companies ask for more documentation, you’ll find yourself making more changes that all of your clinical staff will need to know.

Again, informatics helps to address these needs.

So why haven’t you heard much about this field, even though a lot of large universities teach programs in it? Mostly because it’s so poorly understood by those outside the informatics field.

In my opinion, the term “Informatics” itself lends to an association with “IT”. Unfortunately, as a result, it often gets lumped together with IT from a budget perspective, which hurts the informatics effort because, well, We’ve already got enough people working in IT!”.

Question : So if you need to have “informatics” to help support your EMR, where do you get it?

Fortunately, there are good consultants who will help you understand informatics, and develop an informatics group inside your hospital. The problem, though, is that they probably won’t be able to give you concrete answers to your IT implementation questions – Not without a lot of research first, which can be costly. The informatics answers you need rely on a solid understanding of your clinical workflows, which outside consultants may take time and money to learn.

So you have to look within your organization for those people who know the workflows. And then figure out how to analyze them, and have the governance and administrative support to rearrange them to meet your new electronic world you’re functioning in.

And this is where a good CMIO can help you.

A CMIO (Chief Medical Informatics Officer) is a relatively new position in healthcare, but generally it’s a physician who practices at least part time in your organization, and who can help build and lead an informatics group that will help you determine :

1. What new software features / order sets are needed? (Remember : Translating paper order sets into the electronic world is almost impossible – Be prepared to re-write most of them!)

2. What workflow changes are needed to support the new order sets?

3. What education / training is needed to support the new workflows?

4. What policies are needed to support the new workflows?

In this way, a clinical informatics group suddenly becomes a very useful tool to figure out these issues. If you don’t have a clinical informatics group, your clinical managers will point the fingers at the clinicians who will point their fingers at the IT staff who will point their fingers at the policies, and the cycle will never get broken. In a few months, you’ll start to hear things like “The doctors and nurses aren’t doing what we trained them to do!” and “The software stinks!” and “Why don’t the order sets do what they say?”.

But with a good CMIO, you can start to build a clinical informatics group that starts to tackle these issues, and keep your EMR and informatics culture alive and robust. And you’ll be much more adept at meeting the rapidly-changing needs of modern healthcare. Think of your informatics group as the gardeners tending to your rather expensive garden. (This is what those informatics schools have been teaching!) :)

And sure enough, healthcare’s demand for clinical informatics has suddenly taken off. According to, positions for “Clinical Informatics Jobs” increased 91% from March 2008-September 2009.

Question : So does this mean I have to hire a whole bunch of new people? How do I find them? Where do I find them? How much will it cost? You told me outside consultants might have trouble learning my organization’s clinical workflows!

Relax, fearless reader. For the betterment of healthcare in our nation, I’m going to write more next time to shed some light on ideas you can use to figure out how to develop such a team.

Saturday, November 14, 2009

What is Informatics?

So I've discussed "What is informatics?" in several prior posts.

I stumbled upon this great Powerpoint tonight, as I was working on an article about CMIOs and Informatics.

This is possibly the most well-designed presentation I've ever seen on the importance of medical informatics. Certainly, a must-read for any hospital administrator considering jumping into the EMR bandwagon.

Written by Scot M. Silverstein, MD, a big informatics person at Drexel University who studied informatics at Yale.

A great piece for folks to read, to help understand why informatics is needed to support your EMR.

Wednesday, November 11, 2009

Signal-to-noise ratio

Ever heard the term "Signal-to-noise" ratio?

It's basically an engineering term. It compares the amount of background noise, with the amount of "signal" coming through the noise.

If you've ever seen a car approaching on a foggy day, you've seen the car (signal) through the fog (noise).

Another great example of this phenomenon : The old analog car radio, where you would turn the dial to hear static, until you came upon a "signal" that sounded like normal music/speech - At which point you stopped turning the dial.

I'm writing about this phenomenon because it's starting to affect healthcare.

Ever heard the phrase, "Why don't the doctors read their mail?"

How about "I've tried posters, mails, letters, and lectures - Why is it so hard to train our doctors?"

Here's the reason we docs have a hard time reading mail : EVERYONE WANTS TO TELL A DOCTOR SOMETHING.
  1. I check my physical mailbox about once a week - Even though I try to clean it out, it's generally full every time I return.
  2. I check my email box several times a day - Again, even though I try to read it all, it's generally full with messages every time I return.
I've noticed some administrators struggling with the same difficulty : Imagine if every day you received over a hundred emails - How would you figure out "which is important"?

This is why some people in healthcare have noticed the phenomenon of "things change when someone gets upset enough" - An upset patient, administrator, physician, nurse, or pharmacist is a "signal" trying to get through the "noise".

As the noise level increases, the signals get lost, and eventually :
  • Administrators start to feel, "My clinical staff isn't listening to me."
  • Clinical staff starts to feel, "My administration isn't listening to me."
Eventually, problems that become severe enough, will generate enough signal to get through the noise.

If you want to have a less chaotic environment, it helps to consider this phenomenon - Every extra email and paper mail that goes out only worsens the noise.

And it seems with the amount of people who have something to say about healthcare (regulatory agencies, insurance companies, vendors, outside practices, etc.), the noise level in healthcare seems to just keep getting worse. So the signals have to get louder and louder to get through.

My advice : Think twice before you carbon-copy someone on an email. Do they really need it? Can you wait until later in the discussion to send them a copy?

If we all use our communications a little more sparingly, we'll help make sure that we hear the weaker signals before they become larger signals.

Hidden education and policy challenges

So as I go about my job, trying to get clinicians to use software properly, I'm constantly facing a struggle about workflow analysis and redesign.

Before your eyes start to glaze over, let me explain.

An EMR (Electronic Medical Record), of any type (Cerner, Eclipsys, Soarian, etc.) is an electronic representation of something we used to call a "medical chart".

Sounds simple, right?

The problem is that computers are unforgiving. There is no wiggle room.
  1. An electronic diet order requiring three different fields (diet, texture, liquid modification) to submit a diet will ALWAYS require three different fields.
  2. A paper diet order, even if there are blank spaces to fill in these three fields, can still be submitted with only one field completed - for better or for worse.
So what does this mean? The days of a physician writing "Regular diet" are ending.

So what does THAT mean? That you have to get a physician to understand other texture and liquid modifications, if they want to submit a diet order.

Yes, you read that right : Before, a doctor only had to know what a "regular diet" was. In the electronic world, suddenly, a doctor has to know what a "regular diet, dysphagia I, nectar thickened liquid" diet is.

This is the challenge of every CMIO.

Given the multiple things doctors suddenly need to learn, your doctors start to resent the amount of things they suddenly need to know, that they didn't even think about before. Your choices, to solve this problem, after you go electronic :
  1. Educate your physicians about the new things they will need to know in the electronic world.
  2. Create a new clinical policy that supports the speech-therapists and nutritionists to make the texture- and liquid-modification changes on their own, without doctor support.
  3. Ignore the problem and hope it will go away.
My advice for hospitals going to an EMR, who can't afford a CMIO :

Take a long hard look at solutions #1 and 2 above - Education, and new clinical policies.

This is the hidden cost of EMR adoption that most vendors don't tell you about. But you will be faced with these issues soon after you go EMR.

Education is a problem because, in general, it's hard to educate clinical staff to the level that you need to get docs/nurses/pharmacists nimble enough to feel comfortable with your EMR.

New clinical policies can be a problem because, in general, it's hard to identify what new policies you will need to support the various features of your software. Figuring out which hospital committees are adept enough to figure out the problem, and then champion a policy solution, can also be difficult.

A clinical informatics committee can certainly help address these issues.

A good CMIO can help you establish a solid committee to help address these issues. If you can't afford one, there are good consultants out there who can help you address these issues, but in the meantime, I'll just keep giving away this advice as long as people are reading. :)