Seven things to watch in 2010

Since we're at the end of the year, I thought I'd give you seven things to think about in 2010. These are trends I see happening in healthcare IT, especially with the Meaningful Use criteria upon us. Remember, my list is free, and you get what you pay for. :)

1. Embedded Informaticist - If you don't know what this is today, you will soon. These are the key, crucial people you will need to make your EMR and CPOE efforts work. Without them, your C-suite will eventually confront : Do we rewire our hospital's departments, policy mechanism, and educational/training mechanism, or do we unplug our EMR? Having a good CMIO will help you organize them. Look for a labor shortage in Clinical Informatics as soon as the ink dries on Meaningful Use. Look to the AMIA 10x10 class to help you grow your own embedded informaticists. If you don't have them early in your EMR/CPOE/clinical documentation implementations, you will eventually throw your money away.

2. "CMIO" versus "Physician Champion" - Many places confuse the two. Confuse them at your own peril. In 2010 a lot of places will be learning about the difference between the two.

3. Flower - This project is noble and has teeth. I'm one of the early architects, so how can I not tout it? If you're not sure what Flower is, it's basically a way of cutting through chaos and competition, and developing a clear national healthcare IT standard so that patients medical information is more portable and accessible. We're developing the technical details and marketing. The point? It's going to be a patient-led effort to organize healthcare. Remember : The patient is the boss. Ignore them at your own peril.

4. Confusion - Meaningful Use should be ready soon, and the political landscape is shifting RAPIDLY. The Beacon Communities funding opportunities will be forging new healthcare landscapes and political alliances that nobody ever thought possible. While all of this is promising, how it will actually pan out, and who will not be able to keep up, is harder to predict. Should be an interesting year.

5. Transparency - I see healthcare as needing to become more transparent - The patients are demanding it. Prepare to open balance sheets, have frank conversations that you never thought reasonable, maybe even (gasp!) doctor/administrator/patient partnerships to help build a better community. With healthcare reform in the air, partnerships will be crucial. If your organization isn't politically nimble enough, or your C-suite doesn't get energized on this, the next few years will get more difficult.

6. Healthcare shortages - While most of the healthcare reform seems to be focused on proving more access, little else other than HITECH has any muscle to improving efficiency or costs. As the baby boomers age, we don't have enough resources to provide the care they grew up with. The current healthcare bills don't address tort reform, and in my opinion both the House and Senate bills lack the muscle to turn around our current system. In my head, the bills are like a tiny parachute trying to stop a car from hitting a brick wall. The problem : Some people will point to the bills (tiny parachute) as the "reason the car hit the brick wall". A bigger parachute would help, but in our current system we don't have the political support for that. I expect the "give more access and don't fix the efficiency" approach will be a problem. Be ready for a lot of people to point to the tiny parachute as the reason the car hit the wall.

7. Patient-led reform - As I described in #3 above, the patients are our bosses - Ignore them at your own peril. I'm very impressed with the ePatient initiatives - The patients are figuring out why healthcare isn't meeting their needs - We're all too busy competing! (It's important that they know - They're the boss!) I anticipate the ePatient movement will continue to grow as social media allows them to organize and discuss their beef with modern healthcare. Look for the strong leaders in this movement to accomplish what government and insurance companies and healthcare can't. ePatient leaders also help educate the many, many people who have strong opinions about healthcare reform who actually have little actual experience with healthcare. If there is one place healthcare reform can happen, it's in the ePatient political arena. If I had to fix the nation's healthcare, I would look to some of these people to help lead the political movement, and partnerships between them and front-line clinical staff will be crucial. They have political clout nobody else has.

That's it for now - Hope everyone had a good 2009, and let's all work together to make our good healthcare system even better in 2010!

Flower Power

So a few months ago, myself, and two of my healthcare IT colleagues, Kipling Morris and Nicholas Boisjolie, were sitting around discussing, "Why don't we share information effectively in healthcare?".

As we traced down the multiple reasons, they boiled down to :

1. Government regulations

2. Poor implementation of current healthcare IT technology (many hospitals lack the informatics support to use their EMR well)

3. Competition between EMR vendors.

4. Competition between hospitals.

5. Competition between doctors.

6. A lack of a common standard technical "Esperanto" to let the data flow.

Google Health and Microsoft Healthvault have "cloud-based" EMRs (generally called a PHR - Personal Health Record) - And there are SOME hospitals which transfer their data to these, but it's mainly because Google/Microsoft developed partnerships with these particular hospitals, and invested heavily in developing electronic interfaces.

Still, these required a significant effort to get these places up-and-running. And the rest of us? We would still hypothetically have to send our paper reports to a scanning company who will then make it electronic and transfer it to Google Health / Microsoft HealthVault.

Even though there are a handful of common protocols (.CCD - Continuity of Care Document) and .CCR (Continuity of Care Record) - Most EMRs don't have a standard way of sending the data to these PHRs.

So Kip, Nick, and I were talking about the lack of communication, and how it impacts patient care. We are working hard to improve this, but it seems to be an uphill battle, frought with issues :

1. Political issues
2. Financial issues
3. Educational issues
4. Technical issues
5. Regulatory issues
6. Clinical issues

So we then wondered - Suppose we even DEVELOPED this electronic healthcare "Esperanto" - How would we get all hospitals to start using it?

(If I were a patient, I would want a hospital that spoke this language!!)

So then we wondered : "Why don't patients ask for this?"

The obvious answer : Patients know there is difficulty coordinating their care electronically - And they want better - They just don't know how to help a hospital do this better. (The technical standard to do this would be quite complex!)

So then we wondered : How can a patient ask a hospital to use a particular electronic standard?

And then we thought : What if we gave a NAME to this technical standard - So that a patient could ask for it?

Then we started to imagine : What if Wilford Brimley had a commercial on the Superbowl, where he talked about a hypothetical standard for information interchange : Flower.

"I almost had a medication error because my primary doctor didn't know what my cardiologist had just ordered... And then I almost had an extra echocardiogram in the emergency department because they didn't know what my cardiologist had ordered. But now, with Google Health, powered by FLOWER, all of my doctors can trade their information easily!"

This would introduce the American patient to some concepts :

1. Medication errors happen because of poor information interchange.
2. Extra tests happen because of poor information interchange.
3. Flower is a way hospitals could trade information better.
4. Sharing information better could improve their healthcare.

So then, we imagined : What would happen if patients started asking for Flower by name :

"Dr. Stanley, does your office speak Flower?" "Dr. Stanley, does your hospital speak Flower?"

1. Patients would suddenly show up asking for Flower.
2. Front-line doctors would suddenly start asking administrators about Flower.
3. Hospitals would start asking their EMR vendors about Flower.
4. EMR Vendors would suddenly hear a lot about Flower.
5. To remain competitive, EMR vendors (even legacy systems) would need to speak Flower.

I shared the idea a bunch of times on Twitter, with almost nobody noticing, but it was during a particularly passionate blog thread about patient care where I re-posted it, and suddenly, the idea caught on.

So, it appears I've launched a healthcare technology revolution.

For it to be successful, however, this has to be patient-focused.

We've already given it the formal Twitter hashtag : #hcflower

Keep your eyes peeled - We'll see where this goes...

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. :)

Lack of Informatics support in ARRA/HITECH

I recently had this discussion on http://www.linkedin.com/, 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 LinkedIn.com, 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".

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 : http://tinyurl.com/yhl78e8 )

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 Simplyhired.com, 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.

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.

www.ischool.drexel.edu/faculty/ssilverstein/EHR_benefit_peril_final.ppt

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.

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. :)

Should we rename "Informatics"?

Recently I was talking with some colleagues in healthcare IT, and the random discussion came up : "Should we rename the field of informatics?"

(This, after I'm happy to report that our Clinical Jedis just took a step forward to become what they really are - Clinical Informaticists.)

Let's first ask : WHAT IS INFORMATICS? WHY SHOULD I CARE?

Informatics, as defined by Princeton WordnetWeb (http://wordnetweb.princeton.edu), is "the sciences concerned with gathering, manipulating, storing, retrieving, and classifying recorded information".

The analytic tools of an informaticist, then, include :

1. Artificial Intelligence
2. Cognitive Science
3. Computer Science
4. Information Science
5. Social Science

...all to accomplish certain goals, including :

1. Workflow analysis
2. Workflow redesign
3. Electronic Decision Support

WHY SHOULD I CARE? Because the clinical benefits of an informatics team underscore the importance of early education. A clinical informatics team :

1. Breaks down the "silo" effect (where different tribes / departments / committees "make their own decisions" but don't tell anyone, resulting in downstream chaos)
2. Facilitates interdepartmental communication.
3. Facilitates workflow analysis.
4. Facilitates workflow redesign.
5. Facilitates policy review/design (you will quickly discover which of your policies support your IT, and which don't.)
6. Allows front-line clinical staff to have power to change their environments.
7. Supports the design and implementation of your EMR.

So why rename informatics? Because often administrators and other clinical leaders have difficulty understanding what informatics is. Most common mistake : It often gets lumped together with IT. And while IT and Informatics have a wonderful symbiotic relationship, they are, in fact, very different.

The problem : No good alternative name to pick. Not yet, at least. Yes, I informally call them Clinical Jedis, but it's a little too campy for real use. I suppose there are some potential word candidates that someone could design, but they face the challenge of starting the education from square one.

I think the trick is, then, for your CMIO to educate your administrators about "What-is-informatics?" before and after you go-live with your EMR implementation. The earlier you prepare your leadership for such a group, the easier your acceptance will be of this new paradigm when your informatics team starts to assemble itself.

(If you don't or can't afford a CMIO, then there are good consultants who can help your administration prepare for your culture shift.)

Still, you'll be faced with the challenge: Okay. We accept that we'll need an informatics team. Where do we fit clinical informaticists into our hospital hierarchy? Answer : This is something every hospital administrator struggles with. Generally it ends up being a central part of your hospital's functioning. Your mileage may vary.

(All of this to support our EMR?!?! The vendors didn't tell us about this part, right??)

I think most vendors will say "We told you so!", and in fact they often try to explain this, but the truth is that most of us aren't ready or prepared to hear that message - So even if the vendor tries to explain it, we don't actually receive the message.

So I'm blogging about it to help spread the message before you go-live with your EMR or CPOE. (If you're not ready to tackle these issues, your EMR implementation is going to be challenging.)

(And people often wonder why so many IT/EMR implementations fail within the first year or so...)

EMRs and Governance - Brace yourselves!

So I think probably one of the things they don't warn you about when you "Go EMR" - It really does change the way you conduct business.

Doctors and nurses have to re-think the way they interact.

Nurses and Pharmacists have to re-think the way they interact.

Doctors and Pharmacists have to re-think the way they interact.

It also means Doctors have to be prepared for CPOE.

I've written a little about our "Jedi Informatics Pilot" that we're working on. The group has been super-useful in :

1. Figuring out "What's an IT issue" and "What's a workflow issue" (So far, about 80% of the problems I've investigated have been workflow issues - The other 20% are "IT issues")
2. Of the "Workflow issues", figuring out exactly *what the issue is*.
3. Figuring out how to fix the workflow issue.
4. Figuring out what education and/or policies are needed to support this new fix.

The problem is, that this is a special group that is new to most hospitals.

1. Where do you put such a group?
2. How do you control the "mission creep" of such a group?
3. Who will lead such a group?
4. Do they have adequate support from administration and department directors?
5. How will your traditional committees and departments react to a new group of "Informaticists" dissecting your policy, dissecting your workflows, and reassembling things?

And lastly, one of the possible messy political issues becomes, "If there's a group that has to oversee the implementation of every systems change in our hospital, doesn't it in fact become the police for the hospital?"

And this is a challenge, I think, every CMIO faces as they grow their group - Navigating the political battles as they manage change in the hospital.

(Perhaps, another reason to be "Jedis" instead of "Police" - Has a more benevolent image, and, quite frankly, the "informal" nature feels less threatening to other interested parties.)

But then the difficulty comes - If your informatics group is an "informal" or "loosely-knit" group of clinicians, dissecting their workflows - How will their recommendations be received? Especially when their recommendations mean extra work for other clinicians?

I guess my only advice, to hospitals going through these changes is - Be prepared for the politics of "going electronic". Good IT follows good politics. Bad IT follows bad politics. If you want to be successful at EMR implementation, ask yourself these questions :

1. Do our department directors have any experience with Informatics? (Do they understand what Informatics is?)
2. Do our department directors "get along" in general?
3. Do our front-line clinicians "get along" in general?
4. Is there adequate administrative support for the political and cultural shift?
5. Is there adequate clinician involvement? Do doctors generally show up for extra meetings?
6. Who are the "thought leaders" in the various clinical tribes, and how can I get them to act as ambassadors in the new paradigm?
7. Are our department directors and administrators aware of the culture shift associated with EMR use?
8. Who will be responsible for overseeing this culture shift? (In general, "Leaving it to the vendor" is not the right answer.)

Thanks for all of the comments to my last few blog posts - Always interested to hear people's thoughts. Certainly interested to hear from other CIO/CMIO types to learn of how they handled the governance shift needed for successful EMR implementation.

Are Jedi Informaticists the solution to small IT staffs?

So I thought I'd write more about the "Jedi Informaticists" we're growing at our hospital.

(Yes, the "Jedi" title is informal, and makes everyone smile/cringe when you say it, but bear with me.) :)

I've recently come across CMIO types from larger hospitals who have robust informatics groups. Some have an entire informatics department. Others have large groups of physician champions, data analytics groups, report writers, workflow analysts, and multiple consultants helping to ensure the proper implementation of their EMR.

Smaller hospitals are often pressured to "do more with less", and don't have the budgets to support a large informatics staff.

Currently, we're piloting a group of "Jedi Informaticists" - Representatives from various clinical specialties who identify themselves as "Jedis". (Yes, we are looking for another name, but for some reason, people sort of enjoy the Jedi title - It keeps things informal, keeps it fun, keeps it light, and perhaps most importantly... They get to go home to their families at the end of the day and say "I'm now officially a Jedi." Oddly, this effect, so far, seems to inspire people to show up to meetings more regularly.)

So what is a Jedi, exactly?

A Jedi is a representative from a clinical specialty who :

1. Is committed and passionate about good patient care.
2. Is an excellent clinician (knows what it takes to be a good doctor, a good nurse, a good respiratory therapist, etc.)
3. Knows and is passionate about understanding their *workflows* - Not only what it takes to be a good doctor/nurse/pharmacist/etc., but what information they need, what they do with that information, who they give that information to, and what order they interact with patients in a big-picture-type view.
4. Is committed to "intellectual purity" - The same sort of purity that you get from having a curtain in a voting booth (so you can tell your family you're voting one way, but if you think it's really in the best interest of the country, you can vote the other way, as unpopular as it may be.)
5. Is committed to political neutrality - Thinks mainly of "what is the best thing for the patient", and does not bring their political/emotional baggage to the negotiating table.
6. Is committed to the art of negotiation - Nobody should walk away from a negotiating table unhappy, and *both* people have to be committed to making sure *the other* is happy before negotiations are done.
7. Is IT-friendly, and knows the EMR software well.
8. Is comfortable teaching their colleages (from their clinical tribe) about new workflows and software operations.
9. Has basic "data-mining" capabilities - You provide them with raw data from your EMR, they can use Excel/Statistics packages, and a basic knowledge of descriptive statistics (e.g. gaussian distribution, mean, mode, median, etc.) to understand the functioning and efficiency of their clinical tribe.

Most often, these people are not the directors - But rather, front-line staff who work closely in conjunction with the clinical directors. (Jedis DO NOT replace directors - But they help the directors navigate the IT waters that sometimes can be time-consuming. Ultimately, all decisions are made by the clinical directors.)

Some people have asked me, "What's the difference between a 'Jedi' and a 'superuser'?"

I like to think of it as a Jedi has much more power than a superuser. (Yes, you can laugh. It's intended to be fun and informal.)

Most people think of superusers as clinical staff who know the software and can teach it to other people.

Clinical Jedis, I believe, fill some additional roles :

1. Workflow experts and negotiators.
2. Clinical Data Analytics / Data miners - They help perform CQI for the department.
3. Information gatherers
4. Workflow Trainers
5. Translators : They speak IT for the clinical tribes, and speak their clinical tongue for the IT staff.

So far, our group has grown remarkably in size, and we are looking to "formalize" this position. Some challenges remaining include :

1. Is there a more formal title we can call these people? How does that impact their HR positions?
2. Is there a benefit to "not really being formal"?
3. Where does this group fit in the traditional hospital hierarchy?
4. Who will this group report to?
5. How does one control the "mission creep" of such a group?
6. How does such a group control the number of issues they are asked to tackle, from IT staff (e.g. looking to figure out what the immediate clinical needs are), Clinical staff (e.g. looking to develop IT systems to meet particular needs), Administrators (e.g. looking to increase efficiency in different departments), and Regulatory groups (e.g. looking to ensure that all compliance issues are being met.)

I'm currently helping to guide such a group, and proceeding cautiously and carefully as we start to navigate the twists and turns of meeting the rapidly-changing demands of a hospital going EMR in a modern healthcare environment.

Hopefully some of this will spur some ideas in other folks. Would love to hear from other hospitals about how they handled the governance issues involved in "going EMR".

Oh, and my advice : Don't use "Jedi" label - Not only does it potentially open up a can of worms, there's nothing harder than discussing a "Jedi Council" with a group of physician administrators. :)

EMR = Need for new hospital management tools

So I thought I'd write a little bit more about the cultural shifts that an EMR brings to a hospital. (I say this, after the remarkable success of our "Jedi Informatics" group that seems to be building as we move forward in navigating the culture shift.)

Have you read any blogs about EMR software? Recently I stumbled upon a group of ED physicians who were having a very public discussion trashing various EMR software vendors. I sat there, reading their testimonials, about "The ____ EMR was trash and we had to deinstall it!" and "Another EMR was awful and nobody is using it."

And then I thought... Are they serious?

Yes, I know (as a practicing physician) that EMR software, especially when you get into CPOE, can be a palpable culture shift. (To some, it's a speedbump - To others, it's an earthquake.)

Yes, I know there is some question about how long the efficiency-drag lasts, after implementing an EMR, and some physicians have questioned whether this drag makes the safety / organization worth it.

But then I wonder - How many of those implementations were improperly implemented?

As a former computer programmer, I can also tell you about programs which were well-designed, and well-constructed, but because there was no proper implementation plan, the software sat there, unused.

How many of you can testify about a particular program that "We spent a lot of money on, but nobody used"?

So again, reflecting on this group of ED physicians, who were relating similar stories - I wondered, "What kind of implementation plan did they have?!?!"

Ultimately, I guess, I seriously question : Was it their software, or was it their implementation plan?

As I continue to work in my CMIO role, I explore a lot of "computer complaints" which are perceived as "The computer isn't doing ____ right" - But after detailed exploration and analysis of these multiple complaints, more often than not it relates to :

1. An education / training issue

2. A workflow issue

3. A policy needs to be updated or modified.

... rather than an actual software issue. (Yes, the software appears to be malfunctioning, but when you do an analysis, the root cause of the problem often relates to 1, 2, or 3 above.)

(This is why, some people have asked me, "Why are you discussing so much management and policy? I thought you were supposed to be focused on the computers!?!")

So this brings up the problem : How is a hospital supposed to manage this sort of change? Are our traditional policy mechanisms (such as the Medical Executive Committee) nimble enough to adjust?

And this brings me to my points :

1. Hospitals that handle these changes nimbly will likely have successful EMR implementations.

2. Hospitals that are mired in their old policies/procedures, and fail to develop structures to adjust quickly, will likely have unsuccessful EMR implementations.

Or, more simply put : "Don't think of your EMR as 'an IT thing' - It's 'a hospital thing.'"

Having good leadership to help educate your department heads (like a CMIO) is a good way to ensure your managers understand the questions they'll be asked. Until then, I'll just continue to blog freely. :)

Will write more in my next post about what I'm doing to help adjust this part of the medical culture. :)

Voyage inside the mind of a doctor looking at EMRs and CPOE

Next thought that came to mind - "Why don't the docs like the new system?".

(In CMIO terms, this is the currency we deal in : "Buy-in", as in, "I'm afraid I'm going to lose buy-in if we bring it alive before training is complete.")

So I thought I'd explain how a CMIO is a key role in EMR adoption... And to do this, we'll take a voyage inside the brain of a doctor faced with EMR adoption.

Let me explain...

Your AVERAGE doctor today faces certain challenges :

1. Generally, most docs feel (often rightfully so) that they've lost their autonomy - Regulatory agencies, insurance companies, and other governmental policies have more-or-less mandated certain daily practices that aren't intuitive. Some of those policies add value to patient care, but it is so far removed from the doctor's view, that docs often feel frustrated with these "outside interventions" into "what we're trying to do". (A TIP : If you're an administrator or IT person, be careful about using too many buzzwords - Too many buzzwords, to a doctor, means, "You're not part of my tribe.")

2. Generally, most docs talk to eachother. We have all heard rumors about EMR adoption : That the software is difficult, that it takes a while to learn, that offices and hospitals that adopt EMRs face a sudden slow-down. Lots of docs have "horror stories" that they share about a slowdown in patient care, increase in waiting times, and frustrated staff with initial EMR implementations.

3. A large number of practicing doctors are over the age of 50. Some can type, some still see typing as "something a secretary does for you". These docs are generally somewhat fearful of technology, since it could mean re-thinking their views on typing, or even worse, revealing that there's something they might have trouble learning, or even worse, something they might not be good at - A potential confidence-killer, for docs who need confidence to engage in their stressful practices. (In general, some docs carry a lot of emotional baggage into their EMR voyage.)

4. Very few docs have enough informatics experience or insight to understand the complexities of CPOE. (Not that CPOE is complex, but it requires a new understanding about medication delivery that most docs aren't used to.)

5. Docs practicing "in the paper world" have historically had many things automatically "adjusted" for them by ancillary staff, all along, without them realizing. Going to CPOE means : Nobody is there to adjust your order for you. If it's wrong, you'll get it sent back or get a call asking you for clarification. CPOE asks a doc to order it correctly the first time. Yes, in the end, CPOE can help you be a better doctor, but in the meantime, you'll have a learning curve and find out all of the things you didn't know because other people (nurses, pharmacists) were helping you all along. (This experience adds to the emotional baggage in #3).

6. Most docs are very skeptical about technology support mechanisms - Help desks that don't seem too helpful, training videos that take too long, books that don't "explain what I want in the 5 minutes I have between surgeries..."

So, why I'm glad to be a CMIO : I help smooth out these things.

In bringing a physician into CPOE and EMR use :

1. I try to talk to them and "feel out" their emotional state - Are they nervous? Fearful? Hopeful? What are their opinions about technology? Do they know the potential benefits? What is their "patience level"? These are all important to know, so I can adjust my teaching accordingly.

2. I try to put a personal name and face when I support a doc going to CPOE. I let my docs know, "You can call me anytime, 24-hours-a-day. If you have any problem, I want to know about it so we can fix it." (I'm glad to report that even though I have about 70 docs doing CPOE, the calls I get at night are very, very few.)

3. I remind them that "You will be a different doctor when you're done" - That doctors are going to look and act and think differently in the future, and that this is their way of keeping current and being part of today, rather than languishing in the past. (No doc wants to feel "old and outdated", so this can be fairly motivational.)

4. I remind them that even though there is a learning curve, EMR use actually does help patient care in the big picture - Even though most docs feel that it's "an IT thing", that this simply isn't true - Electronically sharing information with other doctors actually helps improve the overall care for their patients. If they are committed to the best care for their patients, they should be passionate about good information storage and retrieval. (e.g. When docs ask me about IT issues, I ask them where they keep their notes today, and then ask them, "How do your patients benefit from the way you chart today?")

5. I sit with them and personally work on teaching not only the software, but the behind-the-scenes workflows that result in their patient care - From their electronic order, to the pharmacy verification process, to the Pyxis functioning, to the delivery and charting on the eMAR. I feel that the workflows are important so that they can anticipate problems, and know how to adjust their orders when they occur.

6. Lastly, I take a ceremonial "graduation picture" (with my iPhone), and their completed "CPOE exam", for a few reasons :

a. I'd like to keep a historic record of our CPOE adoption, that maybe we can look at in 1-2 years at a holiday party and reminisce.

b. I think it's important to have some sort of ceremony after graduating into CPOE - A doc should walk away with the feeling, "I'm a little different now."

So why a CMIO? Because of the tribal nature of medicine - (See my previous post) - These messages are much more palatable when it comes from another doc, especially, a doc who also worked with you on that really sick patient in the ICU last week.

Again, some of you might not have the resources for a CMIO - A good consultant can also help you improve your training and support, and if not, I'll just keep blogging. :)

Tribal nature of medicine and EMR implementation

This is in response to a request, "Please write more about the tribal nature of medicine"... [And how it impacts EMR adoption]...

Some people are surprised to learn how tribal medicine is, especially those who don't work in healthcare. This was once parodied in the TV show "Scrubs", where the Internal Medicine residents were "Jets" and the surgeons were "Sharks", and they reinacted a medically-themed version of the "West Side Story" dance...

One of the reasons "Scrubs" is so popular with medical people, however, is because it really rings true. The show is actually written by a bunch of doctors who have been successful by making a TV show that parodies the culture of medicine.

So, back to the tribal nature of medicine.

Medicine is full of tribes : The "Doctor" tribe, the "RN" tribe, the "LPN" tribe, the "Pharmacist" tribe, the "Respiratory therapist" tribe...

Doctors even further separate into "Inpatient doc tribe" and "Outpatient doc tribe"... and even among "Inpatient doc tribe", they further separate into "Medicine tribe", "Surgeon tribe", "Cardiologist tribe"...

Nurses have similar tribal divisions, between "Floor nurse tribe", "ICU nurse tribe", "OR nurse tribe"...

The point I'm making is that virtually everyone who works in medicine feels a part of some tribe. Their membership depends partly on their clinical training, and partly on their physical location. It sometimes approaches a quasi-military structure, with various ranks, a semi-formal hierarchy, and a specific method-of-interaction between people of different ranks.

Why bring this up? Because as you start to navigate the culture changes needed to successfully deploy and implement and EMR, you will examine your clinical workflows and be forced to deal with some hard tribal questions : "If the doctor tribe used to do step A, and the nurse tribe used to do step B, and NOW the nurses can't do step B anymore, will the doctor tribe accept doing step A AND B?"...

And when you announce to the doctors that they will need to do step A and B, you will quickly learn about the tribal nature of medicine. Often, discussions about workflow changes and negotiation will dissolve into "MD versus RN", "ED RN versus inpatient RN", "MD versus Clerk", "Clerk versus Respiratory therapist", and so on, and so on, and so on...

This is often the hardest part of managing cultural change in medicine - How do you balance the needs of one tribe versus another?

My feelings about this : A good leader teaches other clinical leaders about two things :

1. The art of teambuilding (breaking down tribal barriers)
2. The art of negotiation (nobody walks away from the negotiating table unhappy.)

To help with teambuilding, the first step is to gather some people from a wide swath of clinical departments : Doctors, nurses, pharmacists, clerks, lab workers, respiratory therapists, and anyone else you can get who is passionate about doing something different. Appeal to them to participate in this new tribe : "By being a part of this new tribe, you can help improve patient care through technology."

Take that group, and to help break down tribal barriers, create a new tribe for those clinical leaders. In our hospital, we've worked hard to create a culture for those clinical leaders, and we look at them as a new tribe.

Once you can get the members of this new tribe to commit to the art of negotiation (in the name of good patient care), it becomes much easier to negotiate workflow changes that satisfy both of their representative tribes.

So far I've remarkable success with this approach, and I'm continuing to pursue this as a model to help with the multiple governance issues which arise from EMR implementation.

This again is something a good CMIO can help you with, but until then, I'll just keep writing. :)

As always, feel free to ask questions! :) Keep 'em coming! :)

Is medical culture ready for EMR and healthcare change?

I've written about the "tribal culture" of medicine a few times on Twitter, and it seems to resonate with people who work clinically, so I thought I'd write a few thoughts about the cultural shift needed for successful EMR implementation.

When people first try to understand the challenges involved with EMR implementation, they commonly reach for common life experiences which they imagine might be similar : Like, for example, installing software on your computer at home or at work.

The problem is that if you use this as your conceptual model for EMR implementation, you will make one of the most common mistakes : Thinking, "...it's like installing software on your computer."

Problems that arise from this conceptual model :

Mistake 1 : The belief that "training" is an instruction book or training class that teaches you to "use the software"
Mistake 2 : The belief that "support" is a help line to answer questions.
Mistake 3 : The focus on "the software" as being an experience at the computer.

Okay, so I'm not being fair in saying that these are really mistakes, since they are certainly useful in starting to understand the enormity of the issue. But if that's where your understanding ends, then you make the bigger mistake of not seeing the bigger picture at work.

"It's not just the software, folks..."

The point I wanted to convey tonight is that "going electronic" is a major cultural shift in healthcare.

1. It means you need to take a hard look at some well-held beliefs, and prepare to readjust them.
2. It means you need to examine your workflows and prepare to resort them.
3. It means you need to build new managerial structures to deal with the culture shift and navigate the tremendous amount of information you will uncover along the way.

So now, the challenge becomes : In addition to buying the software and arranging for starting training and continued support, how do we manage change in a culture that is so fiercely tribal?

So here are my thoughts of useful cultural features to help prepare your office / hospital for this shift :

1. When discussing management or IT : Lose the formal titles of "Doctor" or "Nurse" or "Administrator" or "Pharmacist". (I personally cringe if people use my formal "Dr." title, since I really believe that use of the title reinforces the "us-vs-them" mindset. It's much easier to build a team when everyone feels they're in the same tribe.

2. Take a hard look at the culture your front-line employees live in. Are they nervous to try new things? How do your front-line managers handle their mistakes? If the environment feels too punitive, you will suffer from people not trying the software, and from people not sharing the problems-everyone-should-learn-from.

3. Invest in your employee's skills. There are front-line employees who understand the operations of their department very well, and are interested in being more involved in managerial decision-making. Rather than a the older top-down approach of decisions coming from the top, consider bringing some front-line staff to the top, and let them be responsible for the outcomes.

4. Prepare for new sources of data on clinical functioning. One of the benefits of going to an EMR is that you will suddenly be able to sort through large amounts of data quickly. Things that took hours of chart review in the past now become a quick Excel spreadsheet. Make sure you plan for staff who can help you tap that information and sort through it in a meaningful way. Then develop plans for how to deal with the information you'll obtain.

5. Realize that good teaching is much harder than it looks. It's helpful to talk to anyone who has worked in the educational field about how complicated good education is. (Ask a teacher what the difference between "education" and "good education" is.) You will need to commit to the training and support of a large amount of employees - Are you prepared for that challenge? What resources do you have for this, and when are they available? People will eventually be able to blossom on their own, but generally training will get your employees to a 100-level understanding of your EMR - Eventually, you'll want to bring them up to a 400-level understanding, and that takes resources.

6. Set realistic expectations. It's a simple fact : Some people are impatient. If you have too many of these people, you will have a hard time meeting their expectations early on, and you risk losing confidence and buy-in of your clinical thought leaders. If you focus on setting realistic expectations early on, you'll help avoid the problems that can result from these people.

Sorry it's not a nice list of five things... So it's six. I'm sure I'll think of more in the future.

Thanks for the feedback on the last posts! I look forward to sharing some more insider CMIO tips in the future! :)

Workflow Analysis and Clinical Jedis

Okay, time for Entry #2 -

It's all about the workflow analysis.

This concept is *very* hard to grasp, unless you practice clinically - Either as a nurse, a pharmacist, a doctor, or some other clinician.

"Workflow analysis - It's not just the software and training you have to worry about!"

This is the hidden part that nobody really tells you much about. And if they *do* try to tell you, you probably won't understand it until you're staring it in the face.

Here's the summary : When you go-live with an EMR, you have to re-think your workflows. Basically, if you've never had an IT strategy, you'll be inventing one, whether you like it or not.

It means you have to re-think :

1. What information do I need as a clinician? (Nurse? MD? Respiratory therapist? Dietitian? Pharmacist?)

2. What do I do with that information?

3. Where do I send that information?

4. What order do we do this in, as patients flow through our practice?

5. Who needs access to this information, and when?

The things you used to do on paper often don't translate to the electronic paradigm. And quite frankly, "making the computer do what you did on paper" is a lost opportunity to re-think your IT strategy.

So how do you do this? Who should do it? What governance do you need to do this?

Either, you can look for a CMIO to guide you, or a good consultant who understands this issue very well. Or, you can look to grow your own group of clinical workflow experts and IT training experts.

There's no good term for people who do this new role - Some of us have jokingly called them "Jedis", but they are the clinical operations experts that are hidden in your front-line staff. They are the people in your institution who understand this problem, and can help you understand and maintain the order of your universe.

The first step to taking control of this situation is to identify these allies. In each of your clinical areas you're looking to integrate, look for the person who is :

1. Politically neutral
2. Intellectually open
3. Embraces technology
4. Believes the phrase : "there is no substitute for hard work"
5. Is a respected leader in their clinical specialty
6. Is patient when teaching others.
7. Is *PASSIONATE* about their workflows - Not just "what does it take to be good?", but "What does it take to be good and what information do I need and what order do I need it in?"
8. Is creative
9. Understands the basics of interpretive statistics (Mean, mode, median, SD) and is amenable to some degree of database querying / Excel spreadsheet analysis.
10. Believes *strongly* in the art of negotiation - Nobody walks away from a negotiation unless everyone is happy.

Once you've found that person, hold onto them. They are your greatest asset.

Then start the discussion about "If we went electronic, what information would you need to do your job? What would you expect a doctor to do in a particular clinical scenario? What would you expect a nurse to do in a particular clinical scenario? What should a pharmacist do? etc..."

Start this discussion with the Clinical "Jedis" in one particular department. You will learn a lot about how your unit functions.

You can then work with your IT team to create an IT infrastructure that meets the needs of this new workflow. IT teams have a much better time understanding the clinical demands when the clinical demands are clearly defined.

Then after you agree upon the new paradigm, your "Jedi" can help bring the new workflow and education back to their clinical specialty. And when you "go-live", they can help reinforce good behaviors that fit the new paradigm.

And if your "Jedi" can understand the basics of data analysis (datamining, using Excel or another statistics package), make sure you share your raw EMR data with your Jedis - It will only help them understand your workflows better.

Again - A good CMIO or consultant can help you develop this sort of culture, but I hope I've communicated some of the work that's necessary to give adequate support to your EMR implementation. Please remember that "Jedi" is just an informal term - To avoid problems, you might call them "Clinical Samurai" or "ClinOps expert" or a term of your choice - In fact, I'd be curious if anyone has another term for someone who would fit this position.

Looking forward to hearing feedback. :)