Occupational Hazards of the CMIO

In the last few weeks, I've had a few people ask me more questions about the CMIO role.

Q : "What do you do exactly?" - My parents

A : I implement computing systems and integrate clinical IT. (Makes perfect sense, right?) :)

Q : "Who do you report to, the CIO or the CEO?" - Many Healthcare IT types

A : I report to the CIO - But every CMIO has a different story to tell.

Q : "How do you handle those weird hours?" [in reference to trying to balance clinical time with administrative responsibilities?] - My friends (mostly non-healthcare types)

A : It ain't easy.

Q : "Are you a Chief Medical INFORMATION officer or a Chief Medical INFORMATICS officer?" - Mostly IT vendors or newspaper people.

A : For me - Informatics. I'm proud of the discipline I represent. Geek is cool. :)

Q : "Are you an 'IT doc'?" - Mostly IT vendors or clinicians.

A : Nope. IT is the hardware/software. Informaticists are the folks who implement the IT.

And my recent favorite question deserves a post of its own :

Q : "What kinds of problems do CMIOs have?"

There are a few occupational hazards to being a CMIO. Let me list some.

1. Jaw erosion : From the number of times you'll be explaining why "you can't take the paper order sets and just put them on the screen, it's more complicated than that."
2. Giddiness : From the number of times you'll be accused of "making this more complicated than it needs to be" or "You just made up that word 'informatics'."
3. Depression : From turning your passion for technology into a job, only to find out that the technology is the easiest (and smallest) part of the job.
4. Back pain : From the burden of trying to lift healthcare technology (and healthcare) into the next generation.
5. Angst : From the number of late nights you'll stay awake thinking about "How am I going to integrate all of these legacy systems when we don't have a defined exchange protocol?" and "How are we going to host and publish our clinical apps?" and "Will the docs like my new eSignature MLM?"
6. Eyestrain : From all of the regulations and policies you'll be reading.
7. Dry Mouth : From all of the regulatory and policy questions you'll be asking about and then discussing at many, many meetings.
8. Fatigue : After the "coolness factor" of being in a "new emerging job" wears off, you will soon realize that an enormous amount of sweat equity goes into implementing and maintaining all of these clinical systems.

On a more serious note, I think the hardest issues to contend with are the following :

1. Trailblazing - You're in a job that doesn't have well-defined characteristics! Exciting, right? As a result, there are CMIOs all around the country serving a very wide variety of roles. The fun part: You get to be a trailblazer. The hard part : You can easily work yourself into many, many projects that seem logical to accomplish the goal, which will keep you in the hospital/office for long days.
2. Regulatory / Compliance issues - I think a lot of CMIOs start their jobs because they "like technology". My opinion : This is the wrong reason to become a CMIO. Technology is only a small part of the job. Yes, you're there to "make the technology work", but on a day-to-day basis, you're very removed from the technology. Regulatory and Compliance questions are a mainstay of all clinical integration. When you're mapping out new workflows for your CPOE, you have to be prepared to deal with all of the "messy details" of CMS and The Joint Commission. Prepare to read a lot of regulations, many of which will be vague and outdated, and prepare to make your best estimation of "how things SHOULD work". (The take-home point : It's not going to be as much fun as buying a new iPad and loading your favorite apps onto it!) :)
3. Finance Issues - While a lot of CMIOs have a "dream list" of "what we would like to have happen", often there are budgeting issues to contend with. You'll be helping to decide on projects. You'll be helping to prioritize. But ultimately, you'll be a one-stop-shopping for upset clinicians, and sometimes not have the budget to meet every demand. Part of your job : Help manage the expectation and delivery of different projects.
4. Politics, politics, politics - The job is highly political. Every CMIO has stories of "personality management" and careful delegation that went into their EMR/EHR selection process. Expectation management is also a big part of the job - Many clinicians look to Healthcare IT as a "magic bullet" to prevent everything from med errors to infections to cardiopulmonary arrests. Your job : Make sure people have reasonable expectations about your technology.
5. Education - Most hospitals, after implementing an EMR/EHR, find themselves needing more clinical education resources than ever before. You'll be working on a lot of education pieces, and trying to distill the right message for the right clinicians. And you'll be doing a lot of education yourself, both in meetings and in classroom / training room settings. You'll be teaching everything from CPOE and informatics, to new workflow designs, to statistical data analysis and database queries.
6. Vendor / Technology burnout - The unfortunate truths : Sometimes vendors over-promise. Sometimes government certification committees change their mind. Sometimes clinical circumstances change. Sometimes statewide and national IT initiatives are poorly coordinated. Sometimes certification committees make fast, hard decisions to try to achieve a national goal. Implementing effective solutions can be tough! It's like trying to hit a rapidly moving target while you're standing on a ship in stormy seas. You'll start to ask questions like : "Can anyone deliver on any promises?" "How the heck did we get the telephone to work?" and "I'm amazed that we agreed on 110 volts in all regular houses!".
7. Acronym / Informatics Burnout - Do you have an EMR or EHR? Is ONCHIT or CCHIT in charge of your destiny? What does ARRA say? What about CMS? Do your Dragon voice templates use a push or pull model? Who's connecting your local hospital, a HIE, RHIO, or REC? You'll be learning new acronyms and learning a new language every day. You'll even be going to conferences just to learn the difference between the different acronyms. And then you'll have to translate this new language for your administration and your clinicians.
8. Order Sets, CPOE, Clinical Documentation, Health Information Management, Meaningful Use, Protocols, Data Dictionaries, Workflows - There's a reason no informatics folks are on any primetime medical dramas - It sounds painfully boring. (Can you imagine House, MD, at his next case : "If the damn admission order set were built right, we would have diagnosed this dextrocardia earlier!") :) If the idea of discussing the oevre and gestalt of your General Admission Order Set sounds painful, then this may not be the job for you.

And then, at the end of the day - You think back on all of those early technology innovations. Like AC current. Like 110 volts. Like American Standard plumbing. Like Rotary and touchtone telephones. Like traffic lights. Like driving on the right side of the road. Like the first IP packets being sent over ARPANET. And you think back : Some unsung heroes in past generations worked through all of this to make it a national (or international) standard for us today.

And that's when you get the reward of knowing : I'm helping to build the healthcare delivery model for our children. Maybe it's worth the occupational hazards.

Go into the field at your own risk. :)

So you want to be a CMIO?

So I recently had an interesting discussion with a physician actually asking me, "How do I become a CMIO?".

So far, all of the other CMIOs I know have very interesting stories about how they got into the position. Most of them sound more like accidents than planned career choices, mine included.

Still, I'm totally happy being a CMIO. Yes, it's tough. The hours, balancing clinical and administrative time, can be brutal. And sometimes you feel like you're endlessly herding cats, trying to get people to play nicely as you move your EMR implementation forward.

So I thought tonight I'd write a little bit about the CMIO role.

Question 1 : "What does it take to be a good CMIO?"

I think there are some personality traits that are conducive to being a good CMIO.

1. First, you have to believe in change. And you have to know, and accept, a basic truth : Change is hard. It it was easy, people wouldn't be interested in paying you to do it.
2. It also helps to be nice. If your personality is too strong, people will see you as authoritarian and paternalistic. If you're too weak, you'll never get anything done. You want to be the middle of the road. Top of the bell curve.
3. You need to be able to tolerate ambiguity. If you're the sort of person who needs an idea super-well formed, before you start working on it - You'll never survive. If you're the sort of person who needs every hour of every day planned out - You'll never survive.
4. You need patience. A lot of the job deals with policy and regulatory minutiae. If the idea of writing policies or reviewing CMS regulations makes your skin crawl, this may not be the job for you.
5. It helps to be super-passionate about technology. While Informatics is, in itself, not related to IT (a common mistake!) - It really is important to embrace technology, warts and all.
6. A good CMIO knows when to be detail oriented, and when to let go. Part of the skill is knowing when to be which.
7. A good CMIO is an awesome teacher. There's a big difference between people who call themselves teachers, and people who are teachers. Real teachers are a valuable commodity. Remember, we're all students and teachers all our lives. CMIOs are committed to real teaching.
8. A super-talented CMIO will have "Jedi Skills" when it comes to personality management. Sometimes you have to negotiate politically between competing clinical areas, to reach an agreement, and this can mean some tricky political discussions. They should strive to be as Yoda-like, or Obi-Wan-like, as possible, when it comes to these discussions. Being forceful right out of the gate is often a big mistake. Subtlety and humor are two powerful tools, if used the right way.
9. Finally : It helps to keep a foot in the door clinically. While it's not entirely necessary, realize that the currency that a CMIO spends, to get the job done, is physician buy-in. If the physicians don't respect your opinions, you'll have a hard time.

CMIO magazine recently had an excellent article on CMIOs : Who are they, where did they come from, what do they get paid, etc : See it at http://tinyurl.com/yabcdb9 (or via their web site at http://www.cmio.net ) I highly recommend reading this article if you're considering moving into a CMIO position.

Question Two : "How do I get myself into a CMIO position?"

This is the hard part. Most CMIOs I know have stories about falling into the position. Either they were hired almost by accident, or they were the "loudest complainers" in their hospital, or they were super-involved in their IT department meetings. I think they all share a common pathway : They demonstrated real passion and commitment to change.

The reason it's still hard, is because of the common budgeting pitfalls :

1. Most hospitals don't know what a CMIO is.
2. Most hospitals aren't really sure what Informatics is, so they don't budget for it. (The truth : Most hospitals lump informatics together with IT.)

So when you go looking for a CMIO position, they don't happen often. An organization looking for a CMIO will generally be progressive, have a good understanding of what Informatics is, and have budgeted for informatics. If they didn't do all three, they probably aren't going to be looking for a CMIO.

So my advice : Look for a progressive hospital that knows what Informatics is. And they probably will either have a CMIO, or potentially be looking for a CMIO. And if you're already at a hospital that needs a CMIO, you can create the position by first spreading the word of how important Informatics is for your EMR implementation, and then let your current leaders create a budget for this. (Then recommend yourself for this position.)

That's how a lot of people got into the position - They were active and vocal when the hospital realized they needed someone to help implement their EMR.

Next post, I'll talk about some common pitfalls for CMIOs, and how you can rapidly get seasoned in this new, emerging position.

Medicine Reconciliation and Chaos Theory

So a lot has been written about "What is Medicine Reconciliation?"....

What exactly is this beast?

Yes, medication errors have been reported (such as in this article) to affect 1.5 million people every year (according to the Archeives of Internal Medicine), costing between $77 billion and $177 billion a year.

How do these medication errors occur? Because little is actually known about the information flows for medicine reconciliation.

Here's the problem : Nobody has a good plan for organizing enough to answer the question, "What meds is the patient actually on?"

Here's the scenario : A 60-year-old male shows up in the Emergency Room needing urgent care.

You're the doc responsible for this patient. How are you going to figure out what meds the patient is actually taking?

Potential sources of data include :

1. The patient - Works for some patients, but many don't know the details of their meds.
2. The family - Works for some, but many don't know the details of the patient's meds.
3. The PCP - Works sometimes, but may not know what the specialist prescribed last week.
4. The Specialist - Works sometimes, but may not know what the PCP prescribed last week.
5. The Pharmacy - Works sometimes, but many pharmacies close after 5pm, many aren't electronic, and a lot of patients go to many pharmacies (including mail-order)
6. Electronic "Insurance databases" - Works sometimes, but mainly only with insured patients - Doesn't work if the patient pays out-of-pocket
7. Herbal medications - Often missed as a data source
8. The old hospital record - Sometimes helpful, but sometimes out-of-date. Also remember, except for the VA, virtually no hospital shares pharmacy data with the outside PCPs.

So which of these data sources are you going to use?

What you start to realize is - It's almost impossible to know with 100% accuracy what meds a patient is on.

(Well, maybe in a best-case scenario : A well-educated, non-intoxicated patient, only on one or two medications - Maybe then, you can achieve 100% accuracy. Outside of this scenario, you're generally working at 95% accuracy or less.)

So for the majority of patients, you will never achieve 100% accuracy.

So you have to ask yourself - What level of accuracy is acceptable?

I'm proposing a new standard, which I lovingly call : The Mother Standard.

The Mother Standard is "The amount of data you would collect to achieve a level of accuracy that you would find acceptable for your own mother, knowing that 100% is impossible." I figure, for most people, this is a level of accuracy of >95%.

And this is my proposal, for an acceptable way to perform Medicine Reconciliation to the degree of the Mother Standard (>95%) :

Step 1 : Ask the patient what meds they are on - Including herbal medications. If you, as a clinician, do not feel you've met the Mother Standard - Proceed to step 2.

Step 2 : Ask the family what meds the patient is on - If still not the Mother Standard, proceed to Step 3.

Step 3 : Ask the pharmacy(ies) what meds the patient is on - If still not the Mother standard, proceed to Step 4.

Step 4 : Ask the PCP what meds the patient is on - If still not the Mother Standard, proceed to Step 5.

Step 5 : Ask the specialist what meds the patient is on - If still not the Mother Standard, proceed to step 6.

Step 6 : Check the old hospital/office chart for what meds the patient is on - If still not the Mother Standard, proceed to step 7.

Step 7 : Check the electronic insurance report - If still not the Mother Standard, then at least you can say you made every attempt to achieve the Mother Standard, and were unsuccessful.

So why are there so many errors nationally, every year? Because patients who don't have their meds clearly tracked require an enormous amount of work, just to try to get to the Mother Standard - And in some cases, it's just impossible.

Looking at the coordination of care among multiple specialists, sometimes even multiple PCPs, and hospitals - If the patient, or their family, does not keep track of the meds - Then achieving the Mother Standard is virtually impossible.

Fortunately, doctors are trained to work with incomplete information, but when incomplete information isn't enough, we have to ask ourselves : Who can fix this?

I'm hoping that SpeakFlower (http://speakflower.org) helps our country move into this realm, gradually.

Anyway, I'm hoping to do some research into the time it takes to reach the Mother Standard. Will try to publish what I can shortly. Stay tuned.

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