Are physician informaticists cost-effective?

Another common question you get asked in informatics, especially as a physician is, "Do we really have to pay a physician to do this work?"

This is certainly a valid question - In times when budgets are tight, it's important to question why an organization is paying a physician to do informatics work.

I'm going to present the case about why I think a physician informaticist is cost-effective.

I. BACKGROUND : HOW TO MAKE A CHANGE

The first thing you need to know, to understand the argument, is "How do I make a change?"

To answer this, I'd like to break down the roles you played when you sent your last email - After all, the purpose of all email is to help make some sort of change (either "to own a book from Amazon" or "to inquire about renting a house") :

1. Owner
2. Builder
3. Tester
4. Approver
5. Publisher
6. Monitor

"What's that?", you say? Yes, you actually did all of these roles.

1. Owner - You subconsciously decided, "I need to send an email" and "I will be responsible for what I write" and "I will follow-up on the success of the email."
2. Builder - Based on your decisions, you started to draft an email
3. Tester - You decided to proofread the email before you sent it, to see if it met your quality standards.
4. Approver - After proofreading, you decided "This email is good enough to use!"
5. Publisher - You published the email by clicking "SEND".
6. Monitor - You waited for a response and checked your return emails to see if your email was successful. If needed, you might go back to Step #1.

To make a change in a clinical setting, you basically have to do the same steps, but since you're doing it for someone else, there is a crucial extra step you will need :

1. Owner - Person who owns the tool
2. Builder/Informaticist - Person who designs the tool with the Clinical IT Analyst
3. Tester - Person who tests the tool to "make sure it works as designed" before approval.
4. Approver - Usually a committee who examines the purpose, and the testing data, and approves the tool for use
5. Publisher - Person who publishes the tool for use in the clinical setting (EMR or Printshop)
6. Educator/Implementor - Person who trains clinical staff on the tool - Educates them about how it's published (where to find it), and how to use it.
7. Monitor - Person who monitors the success of the tool after it's implemented, and troubleshoots any problems

And finally, to get to the full list of responsibilities required for designing / testing / implementing clinical tools in the electronic era - there are two last players we will need :

1. Clinical workflows are notoriously difficult to analyze, and so it's helpful to have a Subject Matter Expert, who answers detailed questions about clinical operations and evidence-based practices.
2. Clinical IT systems are very complicated (much more so than sending an email), and so we will need a Clinical IT Analyst to know the programming needed to build these clinical tools, together with the Informaticist. (This role was not needed in the "paper world".)

So this brings us to the final roles that need to be filled to make a successful change in the technologically-advanced clinical setting :


1. Owner - Person who owns the tool
2. Builder/Informaticist - Person who analyzes the workflows and develops standardized tools in conjunction with the Clinical IT Analyst
3. Clinical IT Analyst - Person who develops standardized tools in the EMR in conjunction with the Clinical Informaticist
4. Subject Matter Expert - Person who is responsible for knowing the details of the workflows and being able to cite evidence-based practices
5. Tester - Person who tests the tool to "make sure it works as designed" before approval
6. Approver - Person/committee who reviews the purpose of the tool and testing data and approves the tool for use
7. Publisher - Person who publishes the tool, after approval, for use by your clinical staff
8. Educator/Implementor - Person who trains clinical staff on the tool - Educates them about how it's published (where to find it), and how to use it
9. Monitor - Person who monitors the success of the tool after it's implemented, and troubleshoots any problems.

II. IF YOU HAVE A NON-PHYSICIAN INFORMATICIST :

If your institution has an informaticist who is not a physician, you might have the roles filled as such - Take, for example, the implementation of an order set for your Hospitalist group :

1. Owner = Hospitalist Director
2. Builder/Informaticist = Your non-physician Informaticist who works with your Clinical IT Analyst to build draft of tools
3. Clinical IT Analyst = Person who works with the Informaticist to build draft of tools
4. Subject Matter Expert = Hospitalist Director
5. Tester = Informaticist + Hospitalist Director
6. Approver = (Your order set committee)
7. Publisher = Your Clinical IT Analyst (who publishes the draft by moving it from TEST to PROD environment)
8. Educator/Implementor = Hospitalist Director
9. Monitor = Hospitalist Director

This is a perfectly acceptable setup, but your Hospitalist Director may not have time to fill all of those roles successfully :

1. Ownership - Deciding this does not take long, but...
2. Subject Matter Expert - This can take many meetings to help explain the clincal workflows and evidence-based practices - And depending on how much your director works clinically, he/she may have trouble answering detailed workflow questions.
3. Tester - This can take many hours reviewing tools and workflows and making sure they meet standards for approval - Again, depending on how much your director works clinically, he/she may not be helpful in testing the tool.
4. Educator/Implementor - This can take many hours explaining to staff how to use the tool and where to find it (especially if it's a new tool or something complex)
5. Monitor - This can take many hours to review the effectiveness of the tool - Are the hospitalists using it? Are they using it successfully?

And in a modern medical practice, the changes are coming fast and furious - Every time QA, or an insurer, or a regulatory body say "Jump this high or you won't get paid" - You will need someone to update/maintain all of those tools :

• All of the hospitalist order sets will need constant maintenance
• All of the hospitalist documentation will need constant maintenance (forms, notes, checklists, flowsheets, etc.)
• All of the fancy tools will need constant maintenance (clinical pathways, protocols, etc.)

Every time the FDA makes a change - You will need to maintain all of these tools.

It's a lot for a modern clinical director to manage.

III. ENTER THE PHYSICIAN INFORMATICIST (AKA "EMBEDDED INFORMATICIST" OR "CLINICAL JEDI")

The physician informaticist works with the Department Director to help save time and continously maintain the clinical tools for the department, to keep up with the myriad of evidence/regulatory/billing needs. By training a hospitalist physician in informatics practices, you can develop the following arrangement :

1. Owner = Hospitalist Director

2. Builder/Informaticist = Your physician informaticist

3. Clinical IT Analyst = Your person who works with the physician informaticist to build a draft of tools in TEST environment

4. Subject Matter Expert = Your physician informaticist

5. Tester = Your physician informaticist

6. Approver = Your (order set committee)

7. Publisher = Your Clinical IT Analyst

8. Educator/Implementor = Your physician informaticist

9. Monitor = Your physician informaticist

So in this way, your physician informaticist will play all of these roles :

1. Builder/Informaticist
2. Subject Matter Expert
3. Tester
4. Educator/Implementor
5. Monitor

ANOTHER OPTION : 

You *could* ask your Hospitalist Director to fill these roles, but you will have to pay him/her the salary for this time - Which, as Hospitalist Director ($250k/year?) is probably higher than the physician informaticist ($200k/year?)

ANOTHER OPTION :

If you have a non-physician informaticist, you *could* divide the roles this way :

1. Builder/Informaticist = Your non-physician informaticist
2. Subject Matter Expert = Your hospitalist director
3. Tester = Your hospitalist director
4. Educator/Implementor = Your hospitalist director
5. Monitor = Your hospitalist director

But again, this will mean :

• Having to hire a non-physician informaticist (This could be $50k/year for maintenance.)
• Having to pay your hospitalist director for the extra time it takes to fill all of those roles properly (Even at 0.1 FTE spent on that, that could be $25k/year for maintenance.)

The physician informaticist, by combining so many roles, saves a tremendous amount of time and money, and I believe you will have better maintained/updated/used tools.

By having a hospitalist trained in informatics, he/she can spend 0.8 FTE clinically, and 0.2 FTE on maintaining informatics for the hospitalist group and accomplish most of the maintenance very well, at a cost of about $40k/year for maintenance.

This then sets up the following structure :

1. Hospitalist Director = Makes all of the big decisions about "how things will be run"

2. Hospitalist Informaticist (aka "Physician Informaticist", "Embedded Informaticist", or my personal favorite, "Clinical Jedi") = Helps make Director's dreams a reality and worries about the details to implement them properly and quickly.

In this way, the Physician Informaticist becomes an essential tool of change. And because the tools are built by a hospitalist, buy-in problems are virtually eliminated.

So the next time QA says "Every hospitalist patient will need _________", the Hospitalist Director can work with his/her Hospitalist Informaticist, and relax knowing the details will be worked out, the tool will be rapidly changed, and the implementation will run smoothly.

IV. IN CONCLUSION

For all of these reasons, I believe the "Physician Informaticist" :

• saves both time and money
• improves change-management
• improves departmental accountability (by having an expert in the department managing changes)
• improves quality
• improves reimbursements

... and so, I see this as a rapidly growing role in modern medicine, especially in hospitals who are going EMR or have gone EMR.

Would love to hear any thoughts/comments! Feel free to leave your experiences with physician informaticists!

Why not let docs have their own order sets?

Last week, I was asked a question I'd been asked many times before, by someone who was helping another hospital set up their EMR :

"Why shouldn't we let our docs make their own order sets?"

The reason I was asked this is because many EMR packages have this feature, where docs can make their own order sets for their own convenience. 

REASONS TO LET DOCS MAKE THEIR OWN ORDER SETS :

1. Every doc struggles with efficiency, and making your own order sets certainly is tempting. Why not make order sets that accomplish exactly what you want? After all, if I'm a practicing physician, and I know what orders I 'always put in' in certain scenarios, why shouldn't I be able to make my own order sets?
2. We could save so much committee time if the docs could just make their own order sets!
3. If the docs could make their own order sets, they would probably feel "more comfortable" with order sets and CPOE, in general - Wouldn't this help us with our EMR implementation? Wouldn't we get a higher CPOE rate faster?
4. It would save the time and labor of converting their old paper order sets - (Which, as I've discussed in past postings, are often loaded with embedded protocols which are expensive and time-consuming to engineer out!) - Just let the doctors make their own order sets!
5. If docs could make their own order sets, then they probably wouldn't blame some poor informaticist for making a bad order set for them.

REASONS NOT TO LET DOCS MAKE THEIR OWN ORDER SETS :

1. If every doc can make their own order sets, you have no centralized mechanism for clinical decision support. For example, if your pharmacy previously paid a lot for omeprazole, and it suddenly gets a good deal on pantoprazole, you will probably want all of your doctors to take advantage of the cost savings by steering them towards pantoprazole (when backed by good evidence) - If they all have their own order sets, you won't be able to help guide physician behavior and take advantage of this cost savings. 
2. If every doc can make their own order sets, you also have no centralized mechanism for standardizing care. E.g. an appendectomy could get very different care, depending on which physician was using which appendectomy order set. (Most hospital administrators are trying to standardize care to improve quality and reduce costs.)
3. Order sets need to be maintained regularly, to be kept safe, evidence-based, and efficient. If every doc can make their own order sets, you may quickly end up with many, many different order sets which can be a challenge to maintain, from a technical standpoint. What are you going to do when new guidelines suggest you should be using different drugs to treat pneumonia? How will you find which order sets you need to update? Do you have the resources to keep ALL of your order sets updated? 
4. If every doc can make their own order sets, you will miss out on the opportunity to teach your physicians what informatics is, and how they can improve their own care through evidence-based practice and standardization of processes.

I will admit, as a practicing physician, myself, there are times where I wish I could just make my own order sets. But I will also admit that being challenged on my own order sets is a great learning experience, and ultimately, sharing the discussion with my colleagues, and reviewing the literature is the best learning experience of them all. 

(Apparently I'm not the only one who frowns on personal order sets - A final web page, worth reading even though the author is unclear and this looks more like a comment than a legitimate argument : 

http://www.informatics-review.com/wiki/index.php/Personal_Order_Sets) 

Ultimately, every hospital will need to make this decision for themselves, but remember, as I said - With order sets, there are no free lunches. The rule still applies. :)