Tuesday, April 12, 2011

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.


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.


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.


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
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?)

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.

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!

Sunday, April 3, 2011

What is a Procedure?

For my fellow informaticists, struggling to explain both "why it's more complicated than it seems" and "Still, it doesn't need to be complicated"...  I present : The Procedure.

The procedure is the workhorse of the Informatics Toolbelt. It's the hammer. Or the electric screwdriver.  (In food terms, I suppose it would be the meat-and-potatoes, or the rice-and-beans - depending on  your taste.) :)

The procedure is often the secret key to good informatics work products. It's often unloved, and misunderstood, but you'd be surprised how often I've been asked to "write a protocol" that actually turns out to be a procedure, or series of procedures.

When people talk about "mapping out the workflow", the procedure is often the starting point, the basic building block, and generally sets the framework for the rest of your workflow map.

When trying to map out a workflow, I generally recommend starting with the procedure. Most of the time, you will identify the other tools you need just by starting with the procedure(s).

A good way to teach yourself to think linearly, to write an effective procedure, is to read food recipes. These are essentially procedures. They help you understand the relationship between process and outcomes. (If Procedure = Process, then Policy = Outcome.)

By working out the procedure correctly, you can learn a lot about the safety before the procedure is ever implemented. In this way, well-written procedures can help reduce risk and create clarity.


A procedure is a detailed series of steps that should be taken to accomplish a defined goal. It's the clear list of instructions.
  1. It should not be confused with a protocol. Protocols contain the conditional (IF/THEN) statements that  allow a nurse, pharmacist, or other licensed health professional to start, modify, or stop an order on behalf of the protocol. Protocols are generally turned on/off with a physician order. 
  2. It should not be confused with a policy. Policies are stated goals/standards for the organization. While some procedures are paired with policies ("Policies and Procedures"), the policy is only necessary if you wish to "mandate" use of the procedure. If a procedure is not paired with a policy, it is optional. If a procedure is paired with a policy, then it should be a standard of the organization.
For this reason, procedures are sometimes published :
  1. With a policy - ("Policies and Procedures") - When use of the procedure is a "mandated organizational norm"
  2. Without a policy (e.g. Nursing Procedure Manuals, commonly found on most patient floors) - When use of the procedure is an option

Procedures should be written with clarity, simplicity, and with the end-user in mind. They should carefully balance specificity and ambiguity. Because procedures should communicate "how to achieve the goal", the steps should generally be numbered in order.

For best practice, it is helpful if each line of a procedure generally follows this format :
[ who ] will/may/should/must [ what ] [when] [where] [ why ] [ how
Where :
[ who ] is the person who will perform that step in the procedure, generally best described by job title
will/may/should/must - Choose this wisely. Some people advise never to use "will" or "must" because it creates a very clear standard which can cause challenges if you fail to meet that standard. Speak to your organization's legal counsel for advice about this. 
what ] is the exact activity the person will perform
[ when] is the time they will do it (OPTIONAL - e.g. "Until hands are wet" or "After patient is comfortable", only if needed to clarify the procedure )
[ where ] is the location they will do it (OPTIONAL - only if needed to clarify the procedure)
why ] is the reason they should do this (OPTIONAL - only if needed to clarify the procedure)
how ] is a short description of the way they will do it (OPTIONAL - only if needed to clarify the procedure)
For example, one might write a procedure for washing hands :
  1. Employee will approach sink
  2. Employee will turn on water at sink until water is warm to touch
  3. Employee will rub hands under warm water for 10 seconds
  4. Employee will dispense 10mL of liquid soap into hands
  5. Employee will rub hands together vigorously for 30 seconds
  6. Employee will run hands under warm water for 20 seconds
  7. Employee will turn off sink with elbows
  8. Employee will dry hands with paper towel from paper towel dispenser
  9. Employee will throw paper towel in garbage
This, of course, can be reformatted for simplicity as :

A. Employee will :
  1. approach sink
  2. turn on warm water
  3. rub hands under warm water for 10 seconds
  4. dispense 10 mL of liquid soap into hands
  5. rub hands together vigorously for 30 seconds
  6. run hands under warm water for 20 seconds
  7. turn off sink with elbows
  8. dry hands with paper towel from paper towel dispenser
  9. throw paper towel in garbage
You will notice in the above examples that there are no "IF/THEN" statements. These are best kept to protocols, especially if the procedure involves a nurse/pharmacist/other licensed medical professional starting, modifying, or stopping an order on behalf of the physician.

Remember, that when writing a procedure, one should keep in mind : What will you use the procedure for?
  1. Procedures can easily be converted into "instructions" for patients to use (e.g. if you want a patient to learn how to donate blood)
  2. Procedures can easily be paired with "Policies" to mandate a particular way of doing things (in this way they help standardize care)
  3. Procedures can be left alone, and published in a lone "Procedure Manual", to help your staff understand the best way to accomplish a particular goal.
It should also be asked : Do I need to write this procedure? As you can imagine, once you understand how to write a procedure, it can become tempting to write procedures for everything your organization does. I recommend you only write procedures when there is a :
  1. Clear need to standardize a process (so you probably want to pair it with a policy)
  2. Clear need to educate a process, but don't need it to be mandatory (in which case you probably want to publish it in a lone procedure manual or as a "set of instructions")
Finally, remember that many procedures can be quite complex. If there are multiple team members involved in accomplishing a particular goal, the "who" in each line should be clearly stated, preferrably by job title. For example :
  1. Attending Physician will place order "Consult Gastroenterology" in patient's chart.
  2. Attending Physician will contact GI Consultant to arrange for evaluation and consultation.
  3. GI Consultant will evaluate patient
  4. GI Consultant will order "Milk of Magnesia 30mL PO x1 dose STAT" in patient's chart.
  5. Floor Nurse will give Milk of Magnesia as ordered

Procedures will, like most clinical tools, require monitoring and upkeep. In general, they should be re-reviewed every 2-3 years, or more frequently if needed. For this reason, I recommend that procedures are owned by a clinical or administrative director who has been assigned to monitor and update the procedure as needed.


It is recommended that procedures be written by someone experienced or trained at writing procedures (e.g. an experienced policy writer, informaticist or other specially-trained person), in conjunction with one or more subject matter expert(s).

Because the goal of a procedure is to communicate "how", they should use simple language that an end-user can easily understand.

First, a draft procedure should be constructed by the informaticist and the subject matter expert(s).


The draft procedure should then be tested, in a testing environment, using at least one fictitious but realistic scenario and at least one representative from each job title found in the procedure.

After testing has been completed, the builder/policy writer/informaticist should examine the needs for the procedure, and decide whether :
  1. The procedure should be paired with a policy and published in a policy and procedure manual
  2. The procedure should be published in a lone procedure manual.

After testing has been completed, and decisions have been made (as to whether it needs a policy), the procedure should be brought to a committee for approval.

The committee should examine the goals of the procedure, testing results for the procedure, and the publication plan for the procedure :
  1. Will it be paired with a policy?
  2. Will it be published as a lone procedure?
  3. Does it need to be converted to more patient-friendly "instructions"?
If the approval committee feels the procedure is evidence-based, well-tested, and safe, it should be brought to a vote.

If the approval committee votes to approve, then the procedure may be published for clinical use.

Please note : Some procedures (including many nursing procedure manuals, e.g. Lippincott) have subject matter experts and editors who thoroughly examine/test/vet/approve the procedures for use before publication. These procedures may generally be assumed to have been approved for use by the Lippincott editors, but your organizational standards may vary.


After approval by committee, procedures should be published immediately :
  1. In a Policy and Procedure Manual - For those procedures paired with policies
  2. In a Procedure Manual - (e.g. Nursing Procedure Manuals kept in many clinical areas) - For those lone procedures which do not require policy mandates
Both of these manuals should be kept in the open, in a common place, where all end-users can easily find and review them.


After publication, it is helpful if clinical staff is made aware of the publication of the procedure. Emails, posters, staff meetings, and sometimes classroom instruction can be helpful in educating staff about a procedure.

If the procedure is kept in a common, easily-accessible place, the procedure will require less education effort to be effective.


After implementation/education of a procedure, it should be monitored for effectiveness and safety by the owner.


http://www1.ucsc.edu/ppmanual/pdf/guide.pdf - UC Santa Cruz document about policy and procedure writing, and why policies, procedures, and guidelines should all be kept separate

http://en.wikipedia.org/wiki/Policies_and_procedures - Wikipedia article on Policy and Procedure - Please note the distinction between "Procedures" and "Policies and Procedures". (I also recommend some additions to their "standard template".)

http://www.bizmanualz.com/information/2007/11/12/why-do-you-need-to-write-procedures.html - Good piece about managing risk using well-written procedures

**My absolute favoriteWriting Effective Policies and Procedures : A Step-by-step Resource for Clear Communication by Nancy J. Campbell, AMACOM publishing, 1998. (If you buy one book this year, to help you do this - I recommend this one.)

Hope this was helpful! Would love comments, or your own stories about writing procedures!