CMIO Survival Skills

While a CMIO is there to help implement the technology, so much of the job is process, workflow, and governance. So since I've now been in the role for five years now, I thought I'd take a moment to look back and reflect on the things I've learned in the last five years that I think are valuable CMIO skills.
Here are the 13 most important skills I can think of, off the top of my head, in my usual tongue-in-cheek style : (Remember, as always - Your mileage may vary, depending on your circumstances.)

1. Hospital Governance 101 -  It's not enough to just know the clinical side of governance. You need to know the administrative side too. Both of these wings of hospital governance intersect with each other in different places, and knowing where they meet with your bylaws is vitally important. You will be navigating both, so it pays to know the landscape. Bonus points are awarded if you can diagram your committee structure by heart. :)
2. Document Management - Understanding the basics of how documents are created, drafted, approved, and published is essential. Bonus points are awarded for knowing the details of these steps well - For starters, I wrote a post on the importance of knowing the difference between DEV, TEST, and PROD - These environments typically exist for computer projects, but in reality they apply to all construction and document development (even that email you just sent!). Know them well, why they exist, and how to use them to your advantage in your organization.
3. Definitions and structure of your Clinical Tools - You should know your clinical tools like the back of your hand - Exactly how your organization defines them, drafts and builds them, tests and reviews and vets them, approves them, and publishes them. You should be able to look at them and have opinions on whether they are as effective as they can be. For starters, the CMIO's checklist is a good place to start working on this. Bonus points are awarded if you can recite your organization's definitions off the top of your head. :)
4. Compliance with State and Federal Regulations - You will need to know these well, and will probably be asked to help your organization comply with some of them. Even if you don't know them very well, you need to have a good relationship with your regulatory people, and know where to look when you have questions. Bonus points are awarded as you gradually learn this landscape better.
5. Project Management and managing 'the technical details' - You will need to know the basics of this - Whether or not you have a separate project manager to work with, you will be involved in many projects. Knowing what to expect at different stages when undertaking large month- and year-long projects is very helpful. As for the technical details, you may not want to know how sausage is made, but if you (or your organization) wants to eat sausage (pardon the metaphor), then someone will have to worry about the technical details. If it's not you, then make sure you have a good relationship with the people who understand the details, and work with them closely when undertaking new projects. 
6. Parliamentary Basics - You will probably be asked to chair a committee or two, and be a member of others. Knowing how to properly run a meeting and conduct a committee is crucial. For starters, Robert's Rules of Order is a fantastic place to start. Also make sure you have a formal, written charter - It not only establishes your authority, it establishes the chain-of-command and is essential for good performance and when questions come up. And a tip : Always publish your minutes after approving them at the next meeting. If you wait to format and approve your minutes, they will just build up and you'll have to play catch-up later.
7. Meaningful Use, emerging Health IT Trends, and Workflow Analysis - It's almost impossible to keep on top of every detail, but you should have a good understanding of the Meaningful Use rules, timelines, and how your organization is responding to them. You should also understand the basics and be able to comment on various existing and emerging HealthIT, clinical, and legal trends, including your statewide HIE effort, NHIN, ICD-10, clinical decision support, mobile devices, HIPAA, eDiscovery, etc. Finally, you should understand the basics of workflow analysis and why it's necessary to implement all of this technology. A good way to learn to think in a linear fashion is to read food recipes - This will help you think about the relationship between process and outcomes, and help teach you to write a good procedure.
8. Safety through Information - Safety is not just resident workforce hours and barcoding your medications. Safety needs to be built into all of the documents and information you're overseeing. First, know what a good order set and a good protocol look like - Then learn what good documentation, good policies, good procedures, good guidelines, and good workflows look like. This is one of the big reasons organizations look for a CMIO, so always look for opportunities to improve safety with every tool you see.
9. Networking - Virtually every hospital is going through Meaningful Use together. You will help save yourself a lot of headache if you know the other CMIOs in your area. Use social networking (e.g. Twitter), or call them up, introduce yourself, and meet them just to talk shop every once in a while. The Interstate 91 Informatics group I've set up has been invaluable to me and others in helping to share lessons and best practices. Look to see if there's any regular gatherings in your area, and try to get to at least one of the national conferences every year (e.g. HIMSS).
10. Teambuilding, cheerleading, politics - You will undoubtedly meet other doctors, nurses, pharmacists, and other ancillary staff, and need to meet with them. Often, EMRs demand more collaboration between clinical specialties, so you will have to know how to encourage people to work together. Don't try to play sides or favorites - Treat everyone equally and you'll be able to build those teams.
11. Budgeting realities - Implementing an EMR is expensive. There are costs at every step of the way - Technical costs, training costs, costs to change workflows, staffing costs. "Flexible budgeting" is optimal, but in today's climate, most organizations are focused on cutting costs. Be prepared to work with your budgeting people, and always ask yourself, "What if we don't get everything we ask for?"
12. Informatics Education - Whether you're the "Chief Medical Information Officer" or the "Chief Medical Informatics Officer", you will be discussing Informatics with many people, probably while you are defining this emerging role in your organization. The term is sometimes frightening to people, until they start to understand it. Don't try to teach too much at once - Small, frequent feedings are better, so try to meet with leadership for frequent, short meetings. Bonus points are awarded if you help set up an entire Informatics department.
13. Statistics and Process Improvement - After your EMR go-live, you will probably be asked to help optimize the EMR - That means, looking at the results from go-live, and looking for ways to improve results, e.g. higher achievement of core measures, higher CPOE rate, etc. Learn how to get utilization data out of your EMR, and look for statistical relationships that help you improve your processes. Know what a Venn diagram, control chart, pareto diagram, and fishbone diagram are. Bonus points are awarded if you can write your own SQL code! :)

It has been enormously rewarding to me, and if you find yourself in the role, I hope it's equally rewarding to you. Although the first CMIOs appeared on the scene back in the 1990s, it's still a relatively new position (especially in the northeast), so be prepared for a lot of change and ambiguity when you start down the road. 

As always, I enjoy simultaneous teaching and learning - Feel free to leave questions, comments, or thoughts below!

Informatics Spectrum Disorder

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 dramatically impact 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!)

(Healthcare administrator : Good luck hiring someone who "does Informatics"!)

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 :

1. Clinical Informaticist
2. Nurse Informaticist
3. Physician Informaticist
4. Physician Champion
5. Chief Medical Informatics Officer
6. Chief Medical Information Officer
7. Embedded Informaticist
8. 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".

Wikipedia tries to define health informatics, medical informatics, and health care informatics under their page titled "Health Informatics" : http://en.wikipedia.org/wiki/Health_informatics .

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.

1. The field of Informatics, although it's been around since the 1960s, is still really in its infancy, and is relatively new to healthcare.
2. 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.
3. There's no such thing as a perfect definition.
4. 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...
5. As a result, there are wide salary distributions when looking for "Informaticist", and...
6. 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 :

1. The Autism community could benefit from a definition which balances sensitivity and specificity a little more, and ...
2. 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. :)

The bad news about CPOE and clinical protocols

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.

To get CPOE running effectively, you need complete organizational buy-in :

1. Front-line buy-in, to help design meaningful order sets and implement them.
2. 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.