Learn about front-line clinical informatics, clinical workflow design, and EMR implementation with an experienced CMIO. Open discussion is encouraged, education is a priority. All opinions are strictly my own.

Mark was telling me, that he's spoken to recruiters recently, who had several things to say about CMIOs in general :

The CMIO role lacks formality in the industry (there is a wide variation of job duties among CMIOs)

The CMIO role lacks training in "how an organization works" (a valid criticism for some)

That most CMIOs start the job totally unprepared for the realities.

I will agree, there is a problem with formality. (See my last post about how hard it is to find a good job description, for both CMIO and for the Physician Informaticist).

As for Informatics training, there are certainly informatics training programs out there, the most popular being the AMIA 10x10 class, but there are lots and lots of other "informatics training" programs out there too. It's certainly valid, however, that many CMIOs don't have formal informatics training. My own guess : Many of these informatics training programs are targeted for non-physicians too (since Informatics is not just a -physician job - Nurses have informatics needs, respiratory therapists have informatics needs, dietitians have informatics needs, pharmacists have informatics needs - Anyone who works clinically and wants to manage a clinical process can benefit from this sort of training.)

And as for training about "how an organization works", I'm not sure where one would best get that training. It's not just the CMIO that struggles with this! Some people point to MBA programs, but in all honesty, anyone who has worked in business, student government, and maybe understands Microsoft Office really well has at least some idea about how organizations operate. (Is this really some national secret? Committees and paperwork are more than just conspiracy!) I think this is one of the reasons many CMIOs are Internal Medicine, Hospitalists, or Emergency Medicine docs - These are specialties that are very, very affected by "how the machine runs" - You learn quickly, as a Hospitalist/ED doc, about how an organization runs (or doesn't). :)

Finally - the statement that "most CMIOs are totally unprepared for the job they're getting into", I will admit there is probably some truth to that. (Although the same could be said about any job - Who walks in knowing their job on day #1??)

I suppose if there is a "stereotype" to most CMIOs when they start (myself included), it's that of the "tech-savvy doc", waving around his/her iPhone, talking about who they friended on Facebook last night, tweeting at Starbucks while they order some crazy drink and look down their nose at people who have voice-only cell phones. They read Wired magazine, and seem the most "tech-friendly" of all of the docs in their hospital, and like to see themselves as open-minded and friendly, chanting the mantra, "Think Differently". They're often the first to buy a hybrid car and the latest gadget at Apple, and show it off to all of their friends. And according to CMIO magazine's recent job survey, apparently many are Internal Medicine physicians, male, ages 51-55 years old. (Curiously, 9% are not licensed physicians - Did they not complete a residency? Or just not physicians? Hmmm...)

Anyway, I would say that I fit this stereotype to some degree, when I started, except I worked for several years in the software industry before I went to medical school, so I didn't walk in totally naive about how hard it is to maintain a network and software for a large company.

What I didn't realize, when I got into the position in healthcare, is that unlike private industry, healthcare is much more challenging to implement a large-scale IT project :

In private industry, budgets are much more forgiving about technical snafus that arise. In healthcare, budgets are tight all over.

In private industry, everyone works 9a-5p. In healthcare, employees work 24/7, in different shifts, so training is much more difficult.

In private industry, if you have to train all employees, it's not such a big deal to close a unit of a company for 2-3 days while you train everyone. In healthcare, you can't close the ED for 2-3 days while the doctors and nurses learn the software.

In private industry, it's acceptable if the system works 98% of the time. In healthcare, it's unacceptable if the system works 99.5% of the time. (Engineers will tell you how easy it is to make a system that works 95% of the time, and how hard it is to make a system to work 99.9% of the time.)

These are some of the lessons I learned in my first year performing my job.

So now there seem to be a LOT of CMIOs being hired (for good reason!), and after speaking to a bunch of them, I've been asked to help "train our new CMIO so they hit the ground running". And the first thing I try to tell them is : Yeah, the iPhone and Facebook and Twitter are all great, but you won't be using any of them in CMIO land.

(It's a crushing defeat to the ego, often, but it's the truth.)

These are the things, new CMIO, you should instead look forward to :

You will spend a lot of your time trying to strategize politically about how to get physician buy-in to your informatics platform.

You will spend a lot of your time trying to strategize politically about how to get administrative buy-in to your informatics platform.

You will spend a lot of your time reading CMS and Joint Commission and State laws about medication delivery, ordering privileges, and such.

You will read a lot about industry guidelines in building your front-line informatics tools : Policies, protocols, order sets, documentation, and templates.

You will almost certainly encounter technical boundaries that you'll have to explain to docs who may never be satisfied.

You will almost certainly encounter financial boundaries that you'll have to explain to docs who may never be satisfied.

You will almost certainly encounter political boundaries that you'll have to explain to docs who may never be satisfied.

You will often be asked to be responsible for large, complicated systems, and hopefully, you will also be given proper authority to make changes. (Many CMIOs I speak to say they are hired but not given real authority - See the administrative buy-in problem I speak about in #2 above.)

You will spend time reviewing workflows, and analyzing them, and mapping them on flowcharting software, and developing project timelines and managing your informatics team. (If you're lucky - Some CMIOs have no informatics team to work with.)

Yes, new CMIO, welcome to the role! Leave your iPhone at the door, and prepare to swim in the informational swamp that modern healthcare demands! But remember - The CMIO is actually a clinical position, (not a technical one as many people mistake) and it's probably the strangest trip you'll ever take as a physician. So sit back, take a deep breath, and prepare for the wonders that the job will bring you. Welcome!

Sunday, July 25, 2010

Tonight's post, my readers, is about the frailty of language. More specifically, I want to talk about definitions, the general problems with definitions, how challenging they are to write, and how definitions dramaticallyimpact our daily lives.

If you're reading my blog, you might be a front-line clinician who just got your first job in informatics, and you're looking for helpful tips or advice. If you're new to the field, welcome! You may quickly notice a problem, however - Very few people understand what you do. The reason why : Most hospitals (and hospital administrators) still have a hard time understanding what exactly an informaticist does.

You might also be a healthcare administrator, trying to figure out what informatics is, because you've read about how important it is to have an informatics platform in place to make your EMR implementation run smoothly, for Meaningful Use and other reasons. You are coming here asking, "What is informatics and why do I need to hire informatics people to help with our EMR and meaningful use?".

One of the challenges both the front-line clinician doing informatics, and the healthcare administrator looking to build an informatics platform will both face is the definition of the term "Informatics" itself.

(Front-line clinical informaticist : Good luck explaining what you do to an administrator!)

Why is this position hard to explain, and so hard to hire? The answer lies in the definition of Informatics itself.

Let me explain.

First, there are various positions in healthcare, that all apply to the term "Informatics" loosely. Some of them include :

Clinical Informaticist

Nurse Informaticist

Physician Informaticist

Physician Champion

Chief Medical Informatics Officer

Chief Medical Information Officer

Embedded Informaticist

Bioinformaticist

... or another similar-sounding position. Curiously, each of these positions has a wide variety of job descriptions at different hospitals. The reason that these job descriptions vary so widely is because of the definition of the term "Informatics" and how it applies to "What an informaticist does".

You'll notice, however, it's not much of a definition : "... is the intersection of information science, computer science, and health care. It deals with the resources, devices, and methods required to optimize the acquisition, storage, retrieval, and use of information in health and biomedicine..."

(In other words, this generally tries to define Health Informatics as the 'thing you get by crossing information science, computer science, and health care'.)

I, myself, tried to define informatics in older posts by what it is not : Information Technology. (One of the biggest mistakes you can make is confusing informatics with IT - Mixing the two will result in a budgeting problem that will prevent you from having adequate resources for your informatics platform.) But anyway, I acknowledge that my definition also lacks substance.

So why is it so hard to hire? Because of the challenge of defining Informatics, most popular job salary sites (like http://www.payscale.com) have virtually no data about informatics positions. And when they do, the job descriptions are often very wide, and as a result, the salary data is usually very poor. Consulting groups like Premiere are then challenged with giving labor data for positions that have very poor definition. Their reports are also limited by the poor definitions of informatics.

Q : So... I get it, Dirk - Informatics is limited by the poor definitions. So why hasn't the informatics community come up with a better definition yet?

There are a few reasons.

The field of Informatics, although it's been around since the 1960s, is still really in its infancy, and is relatively new to healthcare.

It's relatively new to healthcare because insurers, pay-for-performance, and Electronic Medical Records have pushed healthcare to develop a wide-spread informatics platform.

There's no such thing as a perfect definition.

As a result, there are a LOT of people who have the job title "Informaticist", who have very different skill sets, and perform a wide variety of different jobs, and...

As a result, there are wide salary distributions when looking for "Informaticist", and...

As a result, there are poor job descriptions for many "Informaticist" positions.

That's not to say that people haven't tried to develop better definitions - AMIA, HIMSS, various standards organizations and professional organizations (e.g. CMIO Magazine, Healthcare Informatics) have collected and published definitions and various articles about these issues, but the problem remains : There is still a pretty wide distribution of people who call themselves "Clinical Informaticist".

To draw an interesting linguistic parallel, Autism research suffers from a similar definition problem.

Q : Dirk - Really???!?!

As a person who thinks about the intersection of information and culture, I think I can make a convincing case for this.

In the 1980s and 1990s, researchers realized that one of the biggest problems for people with Autism was that they often didn't get the early intervention and resources they needed to help them. So the term "Autism spectrum disorder" was created, to help front-line physicians to make a diagnosis that had higher sensitivity and lower specificity. (That's generally what you want to do when you want to get resources to people that need it, earlier - Make the label easier to apply.)

The problem with such a broadening the definition of Autism, however, is that it hampers research into the causes of Autism. When the population of "People with Autism" varies so widely, from very low-functioning to very high-functioning, it becomes extremely challenging for scientists to find "statistical significance" between any risk factor and people labeled under the "Autism spectrum disorder".

One might argue, "Well we need to refine the definition of autism, then, to help the research!". The problem then becomes : If we refine the definition to something very specific, fewer kids will be diagnosed with Autism, and those families may miss out on the resources they need to help them.

In the end, you're always trying to balance sensitivity and specificity. As a result : There's no such thing as a perfect definition.

Establishing even good definitions can be very challenging. Linguists, interpreters, lawyers, and policy makers know how delicate and frail human language really is, and how important good definitions are. And while there are standards organizations that try to help us with these definitions (e.g. AMIA and HIMSS for Informatics, DSM-V for Autism), we should keep in mind that there is no such thing as a perfect definition, especially for something as complicated as Autism or Informatics.

Even the best organizations will publish definitions that all have linguistic limitations - It's up to us to see the costs, benefits, and limitations of the definitions and learn to work with them.

And just as important - I think both the Autism community, and Informatics community, would both benefit greatly from better balanced definitions. Namely :

The Autism community could benefit from a definition which balances sensitivity and specificity a little more, and ...

The Informatics community could benefit from work that increases the specificity of the term "Informaticist".

Yes, this is a pretty esoteric post tonight, but I'll keep working at defining both, and offer my linguistic skills to both communities as much as I can.

In the meantime, good luck explaining informatics to your boss, and good luck hiring an informaticist. :)

Friday, July 16, 2010

So this week, the ONC released the final "Meaningful Use" rules. I'm still going through them, but in general, the response has been pretty warm. A lot of the regulations have been relaxed. Still, the overall message : Your hospital will still have to meet "Meaningful Use" if it expects to benefit from the government reimbursements.

So since I had a few free minutes, I thought I'd share the bad news about the conversion to CPOE. Wait - You probably already know. It's hard.

Front-line buy-in, to help design meaningful order sets and implement them.

Administrative buy-in, to help redesign committee structures and EMR governance, enforce the new rules, and help develop the flexible budgeting required for successful implementation.

And here's the hard part - CPOE is a major culture change for the culture of medicine. Some of our most sacred traditions start to fall apart in a CPOE culture.

"Like what?", you ask?

1. The order "Advance diet as tolerated" - You may have read this in medical school, or in your nursing textbook, but the truth is, this is essentially a protocol. In the paper world, it works reasonably well, because in most patients, nurses can figure out how to advance a diet, and what kind of diet to advance to. In the CPOE world, however, this generally becomes a clinical protocol. In the end : You may need the governance structure to build and approve this protocol.

2. The order "Up ad lib" - You may have also read this in medical school, or in a nursing textbook, and many nurses will tell you "That's part of our practice" - The problem is, in the CPOE world, this also becomes a bit of a clinical protocol. Again, it generally works in the paper world, because in most patients, nurses know how to ambulate someone safely. But in the CPOE world, it requires a better level of definition, and also often becomes a protocol. In the end : You may need the governance structure to build and approve this protocol.

3. The order "These orders only are active in the ED" - This type of order is also really a protocol, which basically instructs : "If the patient leaves the ED, then someone needs to discontinue these orders". This works in the paper world, because nurses (seeing this in an order section of a paper chart) will generally know which orders this statement refers to, and nurses elsewhere will then ignore those orders automatically. In the electronic CPOE world, however, it requires a protocol to make sure someone has discontinued the orders properly. In the end : You may need the governance structure to build and approve this protocol.

Yes, some of these most cherished traditions start to fall apart in the CPOE paradigm. See any of them in your current paper order sets? You can translate them to the CPOE world, but you will need to build a more robust way of accomplishing this same functionality - Unfortunately, it's not that easy to find evidence-based rules for developing these protocols.

Your alternative is to develop order sets without any clinical protocols. These will be easier to implement in clinical specialties which are in-house 24 hours/day (e.g. Hospitalists, ED, ICU, etc.), but will be more challenging for surgical specialties and others who manage outside practices. (E.g. they will get phone calls that they weren't used to in the paper world.)

This is why you will need workflow experts in your organization to help understand the exact details of these workflows, and help you develop your clinical protocols along with your order sets and CPOE. Doing them separately is a much more complex process.

So how does a small hospital tackle these challenges? This is tough! The government (and vendors) don't talk a lot about this part of the process - I can only repeat the mantra : "Installing an EMR is nothing at all like installing Microsoft Word into your home computer" - You should be prepared for significant cultural and organizational changes.

In the end, my honest feelings : An EMR will definitely help you organize and understand your own clinical processes. The lessons you learn are invaluable. The quality and control it can bring you are priceless. But you have to be prepared for the level of change. Are you prepared?

In the end, an experiences CMIO or other informatics professional can help you organize all of these changes. My advice : Doing this without expert help is a little bit like turning a battleship around in a bathtub - You *can* do it, but it's much easier to do with an experienced and knowledgeable navigator.

Each of these tools requires a delicate process to build, develop, approve, and publish them.

And the interesting thing? We don't seem to have a standard policy definition! The SKTM Glossary (http://www.skmtglossary.org) seems to offer mostly technical definitions, and various other web sites seem to have different definitions/labels for this very common tool in healthcare. (Most of the other definitions are related to clinical trials.)

I'm honestly surprised The Joint Commission and CMS haven't stepped in to offer a definition that could be very useful in healthcare policy development and educating healthcare administrators internationally. (Is anyone from CMS or TJC a reader? Email me!)

There are also a bunch of automated software packages and companies that provide automated policy management - Just Googling the options will give you lots and lots of choices. (This must be a big business!)

Saturday, July 10, 2010

When you plug in an EMR into your hospital environment, one of the biggest mistakes (challenges?) is the underestimation of training needs. Hospitals sometimes budget for money around the go-live. In reality, the training budget usually increases as time goes on. (This is one of those "Hidden costs of EMR implementation" that many hospitals don't prepare for.)

So I thought I'd talk about what some common educational tools are, that front-line informatics departments use to accomplish this feat. They include :

1. Department meetings

2. Emails / Paper mailings

3. Posters / Screen savers / Billboards

4. CBT (Computer-based testing)

5. Clinical Superusers

6. Train-the-trainer

7. Classroom instruction

8. One-on-one instruction

9. Electronic Decision Support (Alerts / Order Sets)

10. Clinical Managers / Directors

Each of these tools has distinct advantages and disadvantages. I thought I'd go through each one and offer some insight.

Department Meetings - Department meetings are a good way of getting people to your training - They're not good for much more than that. Trying to communicate how to operate a particular software feature, at a meeting when most physicians/nurses are coming in late, or looking for coffee, is generally a poor way to get across proper EMR technique.

Emails / Paper Mails - Like Department Meetings, emails suffer from a few challenges. First, many doctors have such a high noise-to-signal ratio that emails and paper mails almost never get through. (Notice the stuffed paper mailboxes? Physician email boxes are usually pretty similar.) Next, mail suffers from a lack of feedback - Did the physician actually learn the educational objective? How do you know they spent the time to actually properly understand the objective you were trying to get across? As a result of these problems, both paper and emails are notoriously bad for trying to use as an educational tool. My advice : At best, use them to get your staff to the training you set up. Don't mistake them for a training device.

Posters / Screensavers / Electronic Billboards - It's tempting to consider screensavers and electronic billboards for training - One powerpoint slide, seen intermittently around the hospital, might communicate the educational objective! The problem : You can't really guarantee it's seen by everyone. If the electronic billboard is in your cafeteria, then you'll miss employees who don't get lunch in your cafeteria. If the billboard is by the front entrance, then you'll miss employees who go in the back entrance. And like email, there's no way to know if your clinical staff learned the educational objective. Posters take more time to create, but work by the same principle as screensavers and electronic billboards, and so they suffer from the same geographic limitations, and also don't have a way to determine if the educational message has been received by your clinical staff. My advice : At best, use them to augment your training. Don't mistake them for a training device.

CBT (Computer-based testing)- Computer-based testing (e.g. having little computer-designed tests on your web server) is amazingly tempting. Clinical staff can do the tests at work, or at home. The software packages usually let you track which employee has completed which module, so you'll have great data on who completed their training. The downside is that the development of CBT (Computer-based tests) is much harder than it looks. There is a lot of programming and media development that goes into making a single CBT. So while most people dream of being able to save on teachers, usually they end up paying for people to develop the CBT. My advice : This can be very effective, if you plan resources to set up and maintain the CBT site. Don't underestimate the challenge.

Clinical Superusers - This is one of the most misunderstood terms in EMR education. Some people perceive "superusers" as non-clinical staff who wander around your hospital, usually during the month before and after your EMR go-live, to help "answer questions" and provide on-the-spot remediation. Other people perceive "superusers" as clinical staff who are just "really good with computers" and maybe got "extra training", so they could help the clinical staff who aren't as quick to learn. My advice : If you plan on using superusers, plan their time budget carefully. If your superusers are clinical people, and they have a full clinical load, they will not have much time to help your other staff. If they are non-clinical people, it will cost you money. Prepare a superuser strategy carefully, and prepare to spend money on them.

Train-the-trainer - This is also often mistakenly confused with "superusers". Train-the-trainer, done properly, can be a very effective way at educating a large number of clinical staff quickly. It involves a single person developing an educational tool (e.g. a quiz, usually with 4-5 questions, which tests whether or not a clinical member understood the training. Then the primary trainer needs to go out and find, usually, 5-10 secondary trainers. The primary trainer then teaches the secondary trainers how to teach the educational objectives, and give the clinical staffmembers the quiz designed by the primary trainer. The secondary trainers then go out, and usually complete this short education module with another 5-10 clinical staffmembers each. In the end, it distributes the teaching load, and as each secondary trainer comes back with successful quizzes, they bring it back to the primary trainer who can then keep track of "What percent of our staff completed the educational objectives?". My advice : This is a little like guerilla training. It can be very effective if done properly, but try to save it for the emergency, "Every-doc-has-to-know-this-feature-by-next-month-or-they-won't-be-able-to-sign-into-our-system"-type problems.

Classroom Instruction - Classroom instruction seems like a good way to train clinical staff. The problem is that often it's hard to get the clinical staff to the classroom, and if they don't have non-clinical time budgeted, their attention span and patience will be minimal. If you plan on using classroom time, make sure you have a well-developed curriculum, and you budget time and resources so that your clinical staff can learn in a relaxed atmosphere. Another challenge with classroom instruction, in the modern hospital, is that you generally end up running classes at all shifts - Don't forget your night staff if you're doing classroom instruction. My advice : This is a mainstay of teaching in hospitals, but it has its flaws and problems. Make sure you budget time and resources effectively, and develop a good educational curriculum, and keep it short and concise. My advice : Use this as a workhorse-type solution, but don't think it's going to solve all of your training needs.

One-on-One Instruction - This is often perceived as a nightmare (How can we have the time and budget to have a trainer do one-on-one instruction with all of our clinical staff?), but in the hands of a real teacher, this can be enormously effective. It involves one teacher sitting down with one clinical staffmember, and going through a set of educational objectives. Think of it as "your tutor" in high-school. One-on-one is certainly not good for large-scale training (e.g. all your clinical staff in the next month), but can be useful for small amounts of very intense, personal training. In my experience, one-on-one can be very helpful because as a teacher you can really perceive the learning problems and adjust accordingly. You'd be amazed what clinical staff will confess when they are learning one-on-one. My advice : This is good for "problem cases", and good for "brush-ups", but definitely won't work for major software updates or major workflow changes.

Electronic Decision Support (alerts / order sets) - Some people point to alerts in the software as an educational tool, e.g. "We'll just make a pop-up window that tells the doctors what not to click on". This is a major mistake. A pop-up window is not training. At best, it can help educate a doctor about a possible problem. At worst, your clinical staff may be suffering from alert fatigue, and ignore the alert entirely. Some people look for other electronic decision support (e.g. order sets) as a possible educational tool. While some order sets can be useful in educating your staff (e.g. is there a new antibiotic that you should be using for UTIs? Change the UTI order set to the new antibiotic!) - The problem is generally that EDS is not well-understood by most hospitals, and at best it helps guide clinical staff towards successful navigation of a small workflow issue. My advice : It helps a little, but definitely don't count on alerts or order sets to educate your clinical staff.

Clinical Directors / Managers - While some people don't focus training on clinical directors or managers, mistakenly thinking "only the front-line staff will need to know how to use the EMR!", I can tell you this is a big mistake. Clinical Directors and Managers are exactly the support people that the front-line staff go to for help. If your clinical directors and managers aren't familiar with your EMR software and workflows, then they won't be an effective resource for your front-line staff. My advice : Make sure you have a teaching strategy set up for your clinical directors and managers, and make sure they learn your EMR software. They can be a tremendous asset to the educational process, and in general, departments where the manager feels "I don't need to learn to use the software!" have very poor EMR implementations. The directors need to learn the software so they can be an educational resource for front-line staff.

So what have we learned? "Dirk - None of these sounds that great...." You're right! None of them are perfect. This is why EMR training requires a combination of all of these tools. And to know how much money to devote to which tool, you'll need an EMR educational strategy, which generally includes EMR policy development in your institution.

And how will you develop that EMR educational strategy and EMR policy? By having a good clinical informaticist (or CMIO) to help you with the entire EMR implementation. Remember : Good informatics starts at the budgeting process. Make sure you get expert help early, and don't underestimate the challenge of training and education in the EMR environment. Remember, as I said - The challenges generally get harder after your EMR go-live. Outsourcing training generally doesn't work well, because only in-house trainers will really know your culture and know which tool to apply to which problem.

These are nine tools that almost every hospital uses, to accomplish their day-to-day operations.

The curious thing is that there seems to be little national consensus on the definitions of these tools.

I looked through the Joint Commission, CMS, AMIA, and HIMSS web sites, and was unable to find good policy definitions of these tools.

Most hospitals have as one of their primary administrative policies, a policy that spells out the use of one or more of these tools. But since there is little national consensus, it seems most hospitals have to write that first administrative policy from scratch. (Do I have any readers who can comment more about this?)

So I took my first stab at writing a middle-of-the-road definition of these tools, and put it up on Wikipedia. And within 5 minutes, the Wikipedia editors rightfully told me these entries would be taken down in 7 days if I could not produce proper citations for these tools.

I sought more sources, and was able to find some help on clinical order sets through the Institute of Safe Medication Practices web site (http://www.ismp.org) -

But unfortunately, I'm having significant challenge in finding additional sources.

If you have time, feel free to go to Wikipedia and contribute either sources or edits that could help shape the political, legal, and cognitive framework on which all front-line informatics tools may be built in the future. :)

(In the meantime, I've approached some big people in the Informatics Industry - We'll see where we can get in the next seven days. Talk about a challenge!) :)