Who works in Health Informatics?

So I have had a number of people recently talk to me about health informatics jobs. Being a physician, they are mostly physicians looking for informatics jobs.

The interesting thing is, I get the sense the healthcare industry NEEDS informatics, but isn't really ready for it. The CMIO position, despite being almost 20 years old, is still too new to most healthcare administrators, and from what I see and hear, many hospitals don't really know what to do with one. The job functions, from hospital to hospital, vary so widely.

And then there is the question about exact titles - what's the difference between a "CMIO", a "CNIO", a "Physician or Nurse [Embedded] Informaticist", a "Physician Champion", and a "Superuser"?

I will attempt to wax philosophic here, just in the name of starting the discussion on formal titles and formal job descriptions - which the healthcare industry needs badly, if it wants to take advantage of informatics help. Perhaps eventually this will turn into the holy grail of formalization - An actual Wikipedia page. :)

1. The CMIO (Chief Medical Informatics Officer) - Yes, you do informatics, so you have to believe in political neutrality. Yes, you try to guide the rest of the hospital about informatics issues.  You talk about EMR strategy, you help discuss budgeting issues for a solid informatics platform, you stress the importance of proper training. You monitor and guide the politics of CPOE and EMR in the Medical Executive Committee. You worry about administrative, physician, and nurse buy-in. You may do some training, but mostly you guide the education process. You may do some data mining and quality work. You get involved in project management, and help develop physician and nurse informaticists to work with you. This position is heavily involved in policy, however, and you should prepare to analyze and write a great deal of clinical policies. Lots of regulatory work too. In a smaller hospital, your salary line will probably come from a clinical line, and you will still work clinically. In a larger multi-system hospital, your salary line may come from an IT line, or other administrative line, and you probably won't be working clinically anymore.

2. The CNIO (Chief Nursing Informatics Officer) - The nursing equivalent of the CMIO. Yes, there is a big need for this role. The CNIO worries about administrative and nursing buy-in, and continues to work clinically.

3. The Physician or Nurse Informaticist (aka Embedded Informaticist or my affectionate term, Clinical Jedi Informaticist) - Think a mini-CMIO, but in an individual department. A physician informaticist (or nursing informaticist) is a slightly broader term, and could be an outside consultant called in to help the informatics development of a department in your hospital. The much cooler (and reliable and useful position) is the Embedded Informaticist, the doctor/nurse in a clinical tribe whose paid responsibility it is to develop the informatics platform for their clinical tribe. If the CMIO still works 25% clinically, the embedded informaticist works 75% clinically (and 25% informatics). In an ideal world, the hospital CMIO gets to work with an embedded informaticist in each clinical tribe, to coordinate the workflows between different departments. The embedded (physician or nurse) informaticist then analyzes their own tribe's workflows, maps them, redesigns them, and sees the changes through committees, policy work, and brings them to the Clinical IT staff to make it happen. Since they are embedded, they can also easily train and support the new workflows in their tribe. And because they are embedded, buy-in is never a challenge. The EMR works better, the docs and nurses feel more loved. This is an extremely effective model, by my experience. (If it's supported by administration.) This, I think, is the position that is going to explode in demand in the next year or two. Look out for it. The AMIA 10x10 class will train most of these embedded informaticists. 

4. The Physician Champion - This is a physician who is asked, or paid, to rouse the troops. Your main mission is to be a cheerleader. You encourage the docs around you, and you may get involved in training directly. Exposure to policy and strategy discussions will probably be minimal. You probably won't have the pay or time budget to do much data mining, and you won't be managing other informaticists. Your ability to motivate is much more important than knowing every detail of every workflow. For reasons I don't understand, nursing usually doesn't need a champion, but this may change.

5. The Superuser - This is probably the most misunderstood positions in healthcare informatics today. The superuser is a really, really advanced, highly-skilled educator. They need to know the details of the software and every detail of every workflow. Think of the superuser as an embedded informaticist without the workflow redesign responsibilities. Superusers have to be patient and love education. They don't get involved in the politics or budgeting discussions. And they need to be available, especially at the time of new software or hardware rollouts, to help smooth the transition between classroom training and the clinical front. Superusers are worth their weight in gold, and you can never have enough of them. Not having well-trained superusers makes any clinical go-live a challenge.

Unfortunately, these are all roles in healthcare informatics, but only the CMIO has any semi-reliable job descriptions and pay data. (And trust me, even for CMIOs, the human resources data is still pretty scarce.) Eventually, these all should be recognized, formal roles, but I'm having a hard time imagining a want ad saying :

"WANTED - SUPERUSER FOR #EMR GO-LIVE AT LARGE UNIVERSITY HOSPITAL THIS JANUARY. APPLY WITHIN."

So until we formalize the CMIO, the CNIO, the physician and nurse informaticist, the physician champion, and the superuser - Healthcare won't really be able to take advantage of these very important positions.

In the meantime, I'll keep working on it. :)

The Cost of Hidden (Embedded) Protocols in your Order Sets

I've recently been paying a lot of attention to the cost of hidden and embedded protocols in healthcare. When physicians argue about the efficiency of EMRs, I think this is really what they're talking about.

Let me explain.

Know that tool we commonly use in healthcare, known as the "clinical protocol"? Common examples of this tool found in most hospitals include the "heparin protocol", the "insulin protocol", and the "STEMI protocol". You've probably heard of them.

So what exactly is a protocol?

A protocol is a set of well-defined care instructions and conditional statements which allow nurses, pharmacists, respiratory therapists, and other licensed medical professionals to initiate, modify, or discontinue an order, on behalf of the ordering physician, as instructed by the protocol. Any conditional statements (IF/THEN arguments) in a protocol should refer to a discrete, well-defined data element. Protocols are primarily activated/deactivated by a physician order, but may in rare instances be activated by a clinical policy in situations where regulatory laws permit (e.g. "pharmacy substitutions" are a common protocol/policy combination). Protocols are typically published through a printshop or an electronic site.

Where did that definition come from? CMS? Joint Commission? Neither. I actually penned it. It probably could use work, but it's a start, and since neither AMIA, HIMSS, Joint Commission, or CMS endorses a particular definition of this tool, I had to write it myself. (Feel free to use the definition for your own uses, and comments are definitely welcome!)

Protocols are generally loved by physicians - They generally allow other healthcare professionals to automate a process on behalf of the physician. The Heparin protocol allows nurses to titrate heparin on their own. Respiratory protocols generally allow a respiratory therapist to manage a vent automatically. And so on.

And here's the surprise : Protocols are sometimes found in many more places than just those sheets.

I think the easiest way to spot a protocol hiding somewhere else is the reference to a conditional statement - An IF/THEN - That allows someone to initiate, modify, or discontinue an order on behalf of the physician who ordered the protocol, as defined by the protocol.

So if you use the "IF/THEN" as your guide, try taking a look at your old paper order sets - you may be surprised when you start to notice a bunch of conditional statements (hidden protocols) in them, such as :

1. "Advance diet as tolerated"

2. "Out of bed as tolerated"

3. "These orders are only supposed to be active in the _______ department."

4. "Titrate sedation for comfort".

5. "Use this drug, unless patient is allergic, then use this other drug" (or some variation of that theme...)

From an engineering standpoint - Having all of these little pieces of embedded protocols hidden in your order sets makes it very difficult to convert a paper order set to the electronic form. Why?

Because computers are unforgiving.

1. Electronic Order sets generally go in one specific section of your EMR.
2. Protocols (If/then statements) generally go in another section of your EMR (or your hospital intranet, depending on how you publish them.)

So how did they live, so long, hidden in your paper world?

Because paper is forgiving.

1. Paper Order sets can have "IF/THEN" and other conditional statements in them.

Q : "So Dirk, what exactly is the cost issue then?"

Here's the challenge : In converting paper order sets to electronic order sets, often, depending on the design, you have to decide what to do with these hidden embedded protocols.

You basically have two choices :

1. Develop the protocol, but this often takes a significant amount of time and committee and policy work, OR....
2. You simply leave the protocol out of the new electronic order set.

What ends up happening, often? Order set designers are forced to simply leave out most of these conditional orders (embedded protocols) in the new electronic world.

As a result, this is why, often, the electronic order sets :

1. Don't LOOK like the paper order sets.
2. Don't FUNCTION like the paper order sets.

Q: "So Dirk, again, where's the cost issue?"

Well, here it is : If your electronic order sets have been stripped of all of the hidden, embedded protocols found in your paper order sets -

Then your physicians, on "going electronic", may notice many more phone calls from nurses looking to clarify orders that were previously initiated, modified, or discontinued by these embedded protocols.

And you may notice efficiency changes after you "go electronic".

Q : "Wow. And is there any way to help avoid this?"

It takes a lot of work, but fixing this "hidden protocol cost of EMR implementation" will depend on various factors :

1. How many "hidden protocols" you had in your paper order sets, to begin with. (They generally appear more often in specialties that are not in-house 24/7.)
2. How reliable your protocol framework is.
3. How efficient your committees are at examining protocols for safety and approving them.
4. Your informatics resources, to analyze the workflows, and re-engineering those protocols absolutely necessary for safe workflow to continue.

The cost of not fixing it? Your physicians may sense a significant slowdown after your EMR go-live.

This is where the lack of a Joint Commission-endorsed, or CMS-endorsed definition, causes a problem. By not having a standard definition for hospitals to work with, many protocols go hidden in policies and order sets. (When there isn't a good definition for a protocol, it's easy to engineer them into the wrong tools.)

Avoid the problem by :

1. Trying to avoid these hidden, embedded protocols in your paper order sets, as much as possible.
2. Having a robust informatics platform before your EMR and CPOE and documentation go-live dates, to help analyze the paper order sets and begin re-engineering those protocols that are absolutely essential for proper functioning of your hospital.
3. Making sure your committee structure can analyze these necessary protocols for safety, and approve them in a timely manner.

Again, enjoy! I hope this helps! :)

EMR Training and moonlighting staffing changes

Another change I've noticed in hospitals that "go electronic", especially private hospitals (those without residents), is that the training needs are often hard to meet. I've heard this from several other CMIOs that I speak with.

The training needs for a hospital with an EMR are challenging. Not only is there the initial training (that most software vendors supply at your go-live), there is the training for every new physician you hire, and then there are training needs every time you update your software. In hospitals which employ a best-of-breed approach, which often have many clinical systems, sometimes the training challenges can be daunting.

So it's important for every CMIO to keep tabs of the "minimum training requirement" - That is, what does it take to initiate a new physician to your electronic environment?

Often, especially in a best-of-breed setting, it also means tailoring the training to the specific needs of the physician's clinical specialty.

The challenge, however, is that this training is often no small task. It's not unusual for it to take 3-5 hours as you introduce a new physician to :

1. Your overall electronic landscape and their passwords / accounts
2. Your key workflows that they will be operating in. (The main workflows are important, because they help a new physician trouble-shoot when a portion of the delivery system gets delayed)
3. Your particular EMR, Order Sets, CPOE, and Electronic Documentation
4. Any ancillary systems you may use (e.g. Dictation, Radiology, Billing, etc.)

The difficulty often arises, then, when you have a moonlighter who doesn't prepare for this training time. I'm not sure how the big staffing companies handle this in their contracts, but it seems many companies provide coverage with little advanced notice.

But how will you handle a moonlighter who shows up on the day they are supposed to provide coverage? Or what if you only use the moonlighter "in emergencies"? Or what if the moonlighter only works in your organization once every 3-4 months?

I think, in general, that moonlighting companies will need to respond to the pressures of increased EMR adoption by either :

1. Budgeting and writing contracts that allow the moonlighter for the necessary training time.

2. Perhaps allowing hospitals some preference for moonlighters who have experience with "their EMR"?

Will doctors start adding their EMR experience to their CVs, as a hiring qualification?

The EMR shadow is cast well-beyond the boundaries of the hospital setting! :)

The CMIO's checklist

So as someone who thinks a lot about the informational flows behind a hospital's day-to-day operations, I read a lot about people who are having challenges with "EMR governance issues".

The governance issues you hear about are basically related to change management and implementation issues. After you have an EMR, your training needs expand dramatically. You may need to engineer your paperwork differently. You have workflow issues to contend with, and decision support issues to tackle.

And the committee structure you had before your EMR may not hold up under the new workload demands. Make too small a committee, and you may not get the right input. Make too large a committee, and you may never be able to make a decision.

If the committee charters aren't well-designed, some committees will be overburdened, while others are looking for work to do.

And if you don't have the support to implement your basic tools, then the "ejection fraction" of your committees will drop. (E.g. the committee will decide on a new policy, but if nobody knows about the new policy, then the committee can make lots of decisions that don't really get executed on the floor.)

In short - it helps if you lay out a strategy for how to deal with all of these issues.

So I created this simple little tool, to help a CMIO (or CMIO-like person) figure out how to help orchestrate the "overhaul" to meet your new needs. I affectionately call it, "The CMIO's Checklist". (See the spreadsheet above for an idea of how to build your own.)

With this tool, you first have to come up with a list of your common paperwork design challenges. As an example, most hospitals generally struggle with the timely design, testing, approval, publication, and implementation of the following :

1. Clinical Policies (ALWAYS ON) - A statement describing an organizational standard. Commonly fall into standards for patient care (clinical policies) and employees/non-clinical functions (administrative standards). Typically published through a printshop or an electronic site.)
2. Procedures - Tools which include the detailed steps on how to achieve an organizational standard or defined goal. Typically published attached to a policy statement or in a separate procedure manual.
3. Guidelines - Tools more flexible and negotiable than a policy that are used to outline desired actions and outcomes of therapy.  
4. Clinical Protocols (ON/OFF) - Tools used to standardize and automate care for a common clinical scenario, containing those conditional (IF/THEN) statements that allow a nurse, pharmacist, or other licensed medical professional to start / modify / stop a patient care order on behalf of a physician. All conditional (IF/THEN) statements in a protocol should refer to a discrete, well-defined data element. Protocols are primarily activated/deactivated by a physician order, or in some scenarios by a clinical policy. Common examples include : Heparin Protocol, alcohol protocol, PPI substitution protocol, etc. Protocols are typically published through a printshop or an electronic site.
5. Order Sets -  Tools which include a grouping of orders which can be started / modified / stopped by a physician, used to standardize and expedite the ordering process for a common clinical scenario. Typically categorized as either admission order sets, diagnosis order sets, or convenience order sets, and commonly published either through a printshop or an EMR.
6. Orders - Tools used to instruct a licensed person to deliver a defined type of care to a defined patient at a defined time in a defined manner for a defined duration. Medication orders, referring to the delivery of medications, are typically compiled in a medication formulary and are commonly published via printshop, electronic site, or EMR.
7. Clinical Documentation - Tools used to record and sometimes transmit information about a patient's history, activities, therapies, and responses in time, legally authenticated by a licensed medical professional. Commonly includes notes, checklists, forms, flowsheets, tables, fields, images, movies, and other media. Clinical documentation is typically published through a printshop or an EMR.
8. Templates - Tools that help expedite and standardize the creation of a document.
9. Staff Education Modules - Tools used to educate staff about a common clinical scenario, often including text, slides, videos, recordings, and other media. All staff education modules will include at least three competency questions. Typically published through a printshop or an electronic site.
10. Patient Education Modules - Tools used to educate patients about a common clinical condition or activity, often including text, slides, videos, recordings, and other media. Follow-up questionnaires are recommended. Typically published through a printshop or an electronic site.
11. Staff Schedules - A tool used to define which staff member(s) is/are responsible for a specific type of care at a defined date and time. Typically published through a printshop or an electronic site.

Then, going down the left-hand border of the CMIO checklist spreadsheet, are the following questions that everyone goes through when creating any tool:

1. What is the definition and main purpose of this tool?
2. Who owns this tool?
3. Who builds this tool?
4. Who tests this tool? (Director of Regulatory Affairs? MD? RN? Clinical Director? Risk Management representative? CMO? CNO? COO? What committee(s)?)
5. Who approves this tool? (Med Exec Committee? Forms committee? P&T?)
6. Who codes this tool? (Who comes up with the coding scheme for this tool?)
7. What coding schema do you use? (E.g. a number like #2.12 or ABC-123?)
8. Who publishes this tool? How will your staff be able to find it to use it? In a common place?
9. Who tracks this tool? (What database tracks the tool, it's code, and its approval date?)
10. Who educates/implements this tool? (Who is responsible for spreading the word that a new tool has entered your clinical arena?)
11. Who monitors this tool? (Who looks at the tracking database and checks your quality data to look for problems with the tool or its design process?)

Building and completing a CMIO's checklist is a good way to :

1. Generally figure out where your informatics issues may arise, after you go-live with your EMR.
2. Generally figure out what committee(s) you will need to approve the maintenance of these tools, and how to build those committees.
3. Help your committee chairpeople to better define their charters.
4. Help your middle managers know who is responsible for each part of each tool, when they need to make changes to the clinical setting.
5. Help the people who design these tools understand the definitions, so that you don't have the "feature bleed" problem I've talked about in previous posts.
6. Help employees understand the role(s) they play in the overall functioning of your organization.

You will probably want to try completing one of these BEFORE you go-live with your EMR. If you don't, you may have to adjust your governance issues AFTER your go-live.

Remember - Every hospital will have slightly different definitions of these tools, and fill in different titles and committees into each of these boxes. Why? Because unfortunately, there are not universally standard policy-worthy definitions for each of these tools - CMS and Joint Commission curiously don't seem to endorse definitions - I'm not sure why. (What I've written above is just my own example - You may need to adjust the definitions to suit your needs.)

Enjoy! Hope it helps! Remember, your mileage may vary!

Still no order set short cuts

So today I spent a good part of the day with folks from a hospital preparing for their EMR go-live. I went over the role of the CMIO, how to get buy-in, how to develop an informatics platform, and other things that you need to do before you "go-live" with your EMR.
Remember, in the formula for EMR implementation :

• The CAR = your EMR
• The GAS = 1/2 clinical IT staff, 1/2 Informatics (IS) staff

So we talked about how to budget for your gas, and other issues in getting physician buy-in.
And then, the subject came up about "the order sets". Especially, all of the work that goes into "fixing" the old order sets.
So they reported to me that they were hoping to save some time by just abandoning their old paper order sets, and using some of the "generic electronic order sets" that come with their EMR.
And then I had to break the news to them : Even this won't save you time.

Q : Huh? Dirk, you have posted about how hard it is to fix the old paper order sets. So why can't you just use the order sets that came with your EMR, and tailor them to your needs?

Here's the reason.
Most of your paper order sets (the ones you made before your EMR go-live) actually have little snippets of protocol in them.

Remember, protocols are the "if/then" conditional statements that help automate some nursing process, generally, so your physicians don't get a phone call. (The most common example is the "Heparin protcol", or the "Insulin Protcol", which most people understand fairly well.)
But you probably have other pieces of protocol in your other order sets. Don't believe me? Look at your paper order sets and look for any text that says "If" or "Discontinue when" or "For use in the _____ only", which are all synonyms for "If _____ then ______" - Or, in other words, these are all hidden pieces of protocols.

So the problem you'll have, if you simply abandon your paper order sets and use whatever came with your EMR, is that suddenly all of those pieces of protocol (which are serving you every day) will disappear from clinical function.

And when those hidden, embedded pieces of protocol suddenly disappear from your clinical setting, your docs will suddenly start getting large numbers of phone calls from nurses to clarify these many clinical scenarios.

And this will lead to your CMIO dilemma : When you have your CPOE go-live, suddenly the docs will sense a "serious decrease in efficiency", and the obvious target of their anger will be your EMR. (This is a good way to lose physician buy-in.)

My advice : Repeat the mantra, "There is no such thing as a free lunch when it comes to order sets". Before you decide to adopt this strategy, take a look at your paper order sets. Highlight any pieces of embedded protocol you find (now that I taught you how to find them.) Realize that these protocols will disappear in the electronic world, unless you have the policy mechanism to re-create them as published protocols.

So if you go through all of your paper order sets, and find a lot of pieces of protocols, I wouldn't advise simply getting rid of your paper order sets - Your docs will suddenly feel a loss of productivity and efficiency when you "go CPOE".

I suppose, if you go through all of your paper order sets, you don't find any hidden pieces of protocols, then you may proceed with caution, but if your paper order sets are that well-designed, and your policy mechanism handled protocols well in the past, then these paper order sets won't be too hard to "make electronic" anyway.

(I have yet to meet anyone who has old paper order sets that are built to that level of engineering, but your story may be different.) :)

My closing take-home points :

1. If Informatics were easy, you wouldn't get paid to do it.
2. If Informatics were easy, there wouldn't be schools for it.
3. There is no such thing as a free lunch.

Welcome to the new CMIO!

I was speaking with Mark Hagland today (of Healthcare Informatics magazine), who recently wrote some GREAT articles about Rowing Together (A GREAT summary of the embedded physician informaticist's struggle and rise), Revenge of the Clinical Informaticists and my favorite, my own interview a while back.

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

1. The CMIO role lacks formality in the industry (there is a wide variation of job duties among CMIOs)
2. The CMIO role lacks training in "how an organization works" (a valid criticism for some)
3. 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 :

1. In private industry, budgets are much more forgiving about technical snafus that arise. In healthcare, budgets are tight all over.
2. In private industry, everyone works 9a-5p. In healthcare, employees work 24/7, in different shifts, so training is much more difficult.
3. 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.
4. 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 :

1. You will spend a lot of your time trying to strategize politically about how to get physician buy-in to your informatics platform.
2. You will spend a lot of your time trying to strategize politically about how to get administrative buy-in to your informatics platform.
3. You will spend a lot of your time reading CMS and Joint Commission and State laws about medication delivery, ordering privileges, and such.
4. You will read a lot about industry guidelines in building your front-line informatics tools : Policies, protocols, order sets, documentation, and templates.
5. You will almost certainly encounter technical boundaries that you'll have to explain to docs who may never be satisfied.
6. You will almost certainly encounter financial boundaries that you'll have to explain to docs who may never be satisfied.
7. You will almost certainly encounter political boundaries that you'll have to explain to docs who may never be satisfied.
8. 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.)
9. 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!

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