Informatics Domain and Clinical Workflow Video

Hi readers,

After my last post, some people asked me if I could put it into a video form, to help share with other people.

I was able to condense it into this 7-minute, 23-second video below.

So for anyone who has ever struggled to explain the Informatics domain, how it is related to clinical workflow development, and how it can help create smooth, predictable, reliable, and non-disruptive workflows - I offer up the following : 

Hope it was helpful! Leave your comments and feedback in the comments section below!

Secrets of EMR Governance

The following is essentially a repost of the piece I wrote for the June 2012 HIMSS Insider, with some slight modifications for my blog. (My apologies - my blog allows a higher word count!) :) :

Implementing an Electronic Medical Record (EMR)? Then you’ll want to know something about EMR governance. It’s a subject that’s not well-understood, but in this article I’ll try to provide some background. EMR governance is the process by which you standardize your clinical practices and set them up to work electronically. Without predictable clinical practices, you won’t be able to get predictable clinical outcomes - and because computers are programmed to behave predictably, your EMR implementation will be challenging.

What is governance? 
Although the Oxford dictionary defines governance as “the action or manner of governing,” a quick Google search reveals this NIST (National Institute of Standards and Technology) definition:

“…the controls and processes that make sure policies are enforced.”

So why should clinical professionals worry about policies? After all, aren’t they documents that administrators are paid to worry about?

What is a policy? 
The reason clinical professionals should care about policies is because they are the central nervous system that quietly controls your organization.

Policies are essentially your organization’s standards. They reflect your values and describe, in writing, what you’ve decided to do. If your standard is to give all patients a gluten-free, diabetic cupcake on admission, then your organization could decide to write that standard down on a piece of paper :

“All patients will get a gluten-free, diabetic cupcake on admission.”

Of course, you may decide to pursue more meaningful standards, but for now we’ll use this simple policy as a teaching example.

What is a procedure? 
If a policy describes what you do, then the procedure describes how exactly you go about doing it.

A good model for a procedure is a food recipe. Every line contributes to the end result. For example, to describe how to achieve the cupcake policy above, you might write this procedure:

1. Kitchen staff will bake 100 gluten-free, diabetic cupcakes daily.
2. Couriers will bring cupcakes to floor.
3. Nurses will give cupcakes to patients on admission.

You’ll notice a common theme in the procedure above: Each line answers, at a minimum, the who and what, but also can explain the when, where, why, and how. 
PLEASE NOTE : Some legal advisors recommend avoiding “will” and substituting other terms like “should” and “may.” Check with your legal counsel for advice before writing policies.

Then by having the directors of the Kitchen staff, Couriers, and Nurses review the policy before it gets approved, it allows them to :

• Review the expected workflow - so they can educate it to their staff once the policy is approved, and 
• Budget for it - Do they have the staff and material resources to uphold their part of the workflow?

You will want the directors and their staff to review the drafted policy before it gets approved, so be prepared to spend some time reviewing it with them before it goes for final approval.

When do I write a policy and procedure? 
By writing your policy standard and a procedure describing exactly how to achieve that standard, you now have a very valuable document. Together, these documents give you a meaningful change management mechanism.

Some people, when they learn about policies and procedures, suddenly want to develop policies for everything. Try to resist this urge. Too many policies can make it hard for employees to comply with them. On the other hand, too few policies might mean you’re not standardizing your operations. Ideally, you want a happy medium.

And so, you should only write policies when:

• The policy is required to meet a legal, regulatory, safety, or operations need.
• The policy addresses a common occurrence or practice.
• You have the resources to implement the policy.
• You can enforce the policy.

And, you should only write good policies.

What’s a good policy? 
A good policy is one that creates clarity and harmony in your organization. End-users should be able to find it, read it, and immediately understand your expectations. It should be a valuable management tool for leaders and directors, and should always reflect your values and current practices.

A bad policy is one that creates confusion, chaos, or in a best-case scenario, changes absolutely nothing. A bad policy conflicts with your values, does not reflect practice, is published where few people can find it, and many employees don’t know it exists.

So what about hospital governance? 
Before discussing IT and EMR policies, it helps to understand a little about the difference between administrative and clinical policies.

Let’s say you were building a hospital from scratch—you would need two teams to help you :

1. A clinical team, who know all about giving care, treating diseases, and doing surgeries and procedures
2. An administrative team, who know all about finance and operations and regulations and legal issues.

Neither team can live without the other; virtually all hospitals need both. So we generally divide their standards into:

1. Clinical policies – Those that define patient care and clinical standards.
2. Administrative policies – Those that define employee and administrative standards.

The key ingredient needed for these two teams to work together harmoniously is good communication at all levels of your organization.

So what about IT and EMR Governance? 
After you have a good understanding of your organization’s policy and committee structure, you can go about examining your current standards. Do you have any documents that spell out basic clinical practices such as:

• Electronic Documentation – How/when to create it, sign/authenticate it, use it?
• Medication Order Standards– How/when to order certain medications? Non-formulary medications? In code blue/emergency situations? Over the phone?
• Standards for lab/radiology orders– How/when to order certain tests?
• Training standards – How do you train new employees? Existing employees?
• Clinical Tool Development – How do you develop order sets? Policies? Procedures? Protocols? Documentation? Downtime documentation?

Look for these documents because you will need to examine them and probably modify them after your EMR implementation to help make your processes more efficient. In general, the standards get tighter, and the demand for resources increases after your EMR go-live.

Finally – A common question I hear is, “Where should I publish my IT and Informatics policies? In the administrative or clinical policy manual?” Surprisingly, most informatics and clinical IT policies belong in the clinical policy manual. While it’s tempting to think of them as administrative issues, most of them have a strong impact in clinical functions and strongly impact the day-to-day operations of clinicians. When in doubt, ask yourself: “Who is the end-user of this policy?”

10 DOs and DON’Ts to remember with EMR and Health IT Governance

• DON’T: …write policies in a rush. The more time you spend on them, the clearer and more effective they will become.
• DON’T: …write too many policies. They should only be for things that address absolutely necessary legal, regulatory, or workflow issues, and those that you have resources to monitor and implement. 
• DON’T: …make policies automatically punitive. Non-compliance with a policy should give a leader a reason to pause and reflect: Why didn’t the policy help reinforce the desired outcome?
• DON’T: … forget to document reasons why you knowingly didn’t comply with a policy. They carry legal risk and weight, so any non-compliance should be well-documented and discussed with leadership.
• DON’T: … keep policies hidden! For them to work best, it helps to keep them in a common place where everyone can find them.

• DO: … practice writing policies, and have end-users look them over to help check for clarity.
• DO: … spend time learning your organization’s governance structure, including your bylaws, policy manuals, policy writers, reviewers, and approval bodies.
• DO: … keep reading more and look for classes on operations and policy development.
• DO: … consult legal counsel when needed, especially to tackle tricky, high-risk or other compliance issues.
• DO: … network with other healthcare technology colleagues, to share tips, tricks, and lessons learned.

Secret weapon of the Informaticist : Good policy writing

I've been speaking with various CMIO types, and Informatics types, and found an interesting pattern :

1. "Newbies" - Generally focused on the technology, the software, the bells-and-whistles
2. "Grizzled Veterans" - More focused on governance and change management.

In short, it's probably helpful if you have a little bit of both characters. You will need to worry about the software, the menus, the dialog boxes, the MLMs, your hosting, and your tablet computers if you want to garner support for your EMR implementation. 

But when it comes to making organizational impact, nothing beats being a solid policy writer. A smart policy writer can have much more influence than the best politician/salesman in trying to organize things.

So even though I've written about policies before, I thought I'd write a little bit about the "tricks of the trade". This is the little trick you'll want to keep hidden, your lightsaber you'll carry on your belt. Only wield it when needed, and only use it for good. 

POLICY TRICKS OF THE TRADE 

The first thing, to really get solid with policy writing, is to really grok what a policy is. (For those of you who don't know the word "grok", it comes from Robert Heinlein's book, "Stranger in a Strange Land" - Wiktionary defines it as "to fully and completely understand something in all its details and intricacies.".)

A policy is your opportunity to set a standard. It's a document defining the standard.

The procedure (often linked to a policy by being on the same document) is the steps you take to achieve that standard.

Profound! You could, in fact, write a policy saying that you will be brought a coffee and donut every morning when you show up for work!

What would such a policy and procedure look like?

POLICY : All readers of Dirk's Blog will be brought a coffee and donut on their arrival for work in the morning, according to the procedure outlined below.

PROCEDURE :

1. Minion will bring money to store at 7am.
2. Minion will purchase (1) large coffee with cream and sugar.
3. Minion will purchase (1) chocolate glazed donut.
4. Minion will transport coffee and donut (described above) to office.
5. Minion will await arrival of Dirk's Blog Reader.
6. Minion will give donut and coffee to Dirk's Blog Reader, on their arrival.

It's really as simple as that. And yet, it's complicated...

It's complicated because people don't generally think that clearly without training. It's really easy to get clouded up, especially in healthcare, where you are trying to satisfy many regulatory issues, and dealing with very technical procedures.

But alas, I'm here to provide some guidance!

THE POLICY

The basic format of a policy can be written using this template :

[ who/what ] will [ what ] [ how ] [ when ] [ where ] [ why ]

Where : (blue = mandatory, brown = optional) 

[ who/what ] = The person/thing that is being standardized

[ what ] = The standard that is being applied to the who/what above

[ how ] = How the standard will be achieved ("according to procedure below" is OK!)

[ when ] = Optional, only use if it helps clarify when the standard should be applied

[ where ] = Optional, only use if it helps clarify where the standard should be applied

[ why ] = Optional, only use if it helps clarify the purpose of the standard

  Try it out! Here are some examples of good policy statements :

1. All patients will receive low-fat meals.
2. All patients over age 60 will receive a pneumonia vaccination before discharge.
3. All policies will be clearly written, according to the procedure outlined below.
4. All order sets will be evidence based and built according to the procedure outlined below.

And some examples of bad policy statements :

1. Patients should receive low-fat meals because it helps prevent heart disease. (Wordy, and never use the word "should" in a policy - "Will" is a stronger word!)
2. Pneumonia vaccines are helpful in preventing pneumonia, and so this will be given to any susceptible patients over age 60 before they are discharged by the nurse. (Too unclear and wordy!)
3. It is imperative that policies should be written in a manner consistent with easy comprehension. Policies should be developed in a clear, logical manner. Policies will be kept in the policy manual after approval. (Too wordy, vague, and starts to put procedure into the policy statement!)
4. All order sets will be evidence-based. (Nothing pointing a reader to the procedure below which, hopefully, explains how to build them in an organized fashion.)

Once you've mastered writing a good policy statement, you can proceed to the procedure.

THE PROCEDURE

The procedure is the "how to achieve the goal."

The best way to write a clear procedure is, again, to explain the who, what, when, where, how, and why, which together will tell you "how to achieve the goal".

Again, a template for thinking about it - You will need a series of steps :

1. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
2. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
3. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
4. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
5. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
6. ... and so on ...

Where :

[ who ] = Person who will actually perform the task

[ what ] = Task they will perform

[ when ] = (usually optional) when / until when they will perform it

[ where ] = (usually optional) Where they will perform it - Only use if needed for clarity

[ how ] = (usually optional) How they will perform it - Use only if needed for clarity

[ why ] = (usually optional) Why they will perform it - Use only if really needed (rare)

Think of it as a recipe - In fact, most recipes are procedures! From Allrecipes.com you can find this New York Cheesecake Recipe and easily convert it to a procedure :

1. Baker will preheat oven to 350 degrees
2. Baker will grease a 9-inch springform pan
3. Baker will, in medium bowl, mix graham cracker crumbs with melted butter
4. Baker will remove mixture from medium bowl and press mixture onto bottom of springform pan
5. Baker will, in a large bowl, mix cream cheese with sugar until smooth
6. Baker will blend in milk
7. Baker will mix in eggs one at a time
8. Baker will mix in sour cream, vanilla, and flour until smooth
9. Baker will pour filling into prepared crust
10. Baker will place crust and mixture into preheated oven for 1 hour
11. Baker will turn oven off and let cake cool in oven with the door closed for 5-6 hours
12. Baker will remove cake from oven and chill in refrigerator

Of course, seeing all of the "Baker will..." statements is sort of cluttered, so you might make it look a little tidier :

Baker will :

1. preheat oven to 350 degrees.
2. grease a 9-inch springform pan.
3. in a medium bowl, mix graham cracker crumbs with melted butter
4. remove mixture from medium bowl and press mixture onto bottom of springform pan
5. in a large bowl, mix cream cheese with sugar until smooth
6. blend in milk
7. mix in eggs one at a time
8. mix in sour cream, vanilla, and flour until smooth
9. pour filling into prepared crust
10. place crust and mixture into preheated oven for 1 hour
11. turn oven off and let cake cool in oven with the door closed for 5-6 hours
12. remove cake from oven and chill in refrigerator

And of course, in healthcare, this can be even a little more complicated, because you may have multiple characters. If you do, then you just have to separate the characters based on the role they will play in achieving your policy standard. For example, if the policy goal is "All dance performances by Fred Astaire and Ginger Rogers will leave audiences happy", then your procedure might be :

A. Fred Astaire will :

1. approach Ginger Rogers on dance floor.
2. listen to current music
3. choose dance style that is appropriate for current music.
4. lead dance that is appropriate for music.

B. Ginger Rogers will :

1. follow dance led by Fred Astaire.
2. demonstrate amazing dancing.
3. smile for audience.

C. Audience will :

1. observe talented dance performance by two dance superstars.
2. applaud after dance performance is completed.

IN CLOSING 

Remember, the key to good policy and procedure writing is clarity. Less is often more. "Generous use of white space" is what was recommended to me once. It takes some practice, but once you learn the pattern to good writing, it doesn't need to take too long. In fact, you eventually get to the point where someone is discussing a problem, and you can start to envision the policy and procedure in the top of your head.

This is why good policy writers are worth their weight in gold - Good policies can help you make change, achieve clarity, and save your organization time and money. Bad policies do not make any organizational change, do not achieve any clarity, and will cost your organization in both time and money.

I hope this helps turn you into a policy ninja! Remember, use your powers only for good, and go out there and write good policy!

Would love to hear other people's stories about writing policy and how it related to their EMR implementations! If anyone has any questions, please let me know! :)

The Policy that will realign your hospital's tires

So I've been writing a lot recently about governance, and policy manuals, and how these are poorly understood mainly because nobody writes an instruction manual for a hospital. (That is, of course, with the exception of this blog.) :)

I figured I'd give insight, tonight, by giving you the clinical policy that will lay out the framework to :

1. Realign your governance
2. Re-engage your committees and physicians
3. Improve communication
4. Streamline policy development

So if your Policy Manual is your "sacred text" whereby your hospital operates...

And if your :
   1. Clinical policies - Refer to patients and patient care issues
   2. Administrative policies - Refer to employees and employee/hospital issues

Then you will want a Clinical Policy #1 that lays out your clinical policy manual, and an Administrative Policy #1 that lays out your administrative policy manual.

So for tonight, I present : The DRAFT CLINICAL POLICY #1 that will inject your hospital with new life. Look at it, and feel free to comment! Let me know what you think. (Remember, this is for education / discussion only - Your mileage may vary, and remember, with any free discussion - You get what you pay for!) :)

DRAFT VERSION - CLINICAL POLICY #1


I. Purpose : To outline the organization, development, publication, implementation, and monitoring of clinical policies at Acme Hospital


II. Policy Statement : All clinical policies at Acme Hospital will be owned, designed, formatted, tested, approved, published, implemented, and updated according to the procedures outlined in this document.


III. Scope : This document applies to all clinical policies at Acme Hospital.


IV. Definitions :

1. Policy - A written goal for the organization. Policy statements should be short and succinct, and written in clear, concise, and simple language. 
2. Procedure - The detailed outline of steps staff members should take to achieve the policy goal. Procedures should be written with the user in mind, and should be developed by users.
3. Clinical Tools - Documents and other tools which are used to guide the delivery of safe and effective patient care. These may include, but are not limited to clinical policies, procedures, documentation, order sets, protocols, guidelines/pathways, templates, staff schedules, patient education modules, staff education modules, clinical committee minutes, and committee charters. 
4. Clinical Policy Coordinator - The person responsible for the overall functioning of the clinical policy mechanism at Acme Hospital.
5. Chairperson of Medical Executive Committee - Traditionally, this is the President of the Medical Staff.
6. Owner - The person responsible for the timely review, updating, and dissemination of policies and procedures.
7. Builder [Informaticist, if your hospital is that progressive] - A trained person responsible for the design and testing of clinical tools before they are brought to a committee for approval.
8. Testing - The phase of policy development where a policy is checked for accuracy, safety, and reviewed by at least two end users before being brought to a committee for approval.
9. Approval Committee - A committee with the delegated authority to approve clinical policies, as designated by the Medical Executive Committee through a committee charter approved by the Medical Executive Committee.
10. Approval Committee Chairperson - The chairperson responsible for conducting meetings of an approval committee.
11. Publication - The process by which a clinical policy is published in a common clinical policy manual.
12. Implementation - The process by which a clinical policy is educated to front-line staff and enforced by directors and managers.
13. Monitoring - The process by which the owner continuously monitors the effectiveness and safety of a clinical policy.

V. Procedure : All clinical policies will be :

1. Owned : By a department director assigned by the Chairperson of the Medical Executive Committee.
2. Built : By an assigned builder [informaticist], assigned by the Clinical Policy Coordinator.
3. Formatted : According to the format outlined in Attachment A : Format of a Clinical Policy.
4. Tested : By the assigned builder [informaticist] and the owner, before presentation at an approval committee, using at least two front-line clinical staff members provided by the owner.
5. Presented : Shall be presented by the builder and owner to an approval committee assigned by the clinical policy coordinator. 
6. Reviewed : Shall be reviewed by the assigned approval committee. 
7. Approved : If a motion is raised to approve the tool for use, and the motion is approved, the approval committee chairperson shall document a vote of approval by signing the clinical policy during the meeting. In the event of a tie vote, or if the committee chairperson feels the policy has been incorrectly assigned, the policy may be referred back to the MEC president and Clinical Policy Coordinator for reassignment. 
8. Published : In a common policy manual organized by chapters outlined in Attachment B : Organization of the Clinical Policy Manual.
9. Implemented : By the assigned builder [informaticist] and owner.
10. Monitored : By the owner

VI. Owner :       President of the Medical Staff

VII. Builder :      Chief Medical Informatics Officer

VIII. Tested by : 

             Regulatory Affairs, December, 2010

             Senior Leadership, December, 2010

             Chief Nursing Officer, December 2010

             Chief Medical Officer, December 2010

IX. Keywords : Clinical Policy Manual, Clinical Policy, Administrative Policy, Owner, Builder, Testing, Approval, Approval Committee, Chairperson, Medical Executive Committee, Publication, Implementation, Monitoring

X. Approval Committee :

         Medical Executive Committee, January 2011

XI. Approval Date :     

Approval Body Chairperson :   _________________________________________________

                                                  Chairperson, Medical Executive Committee             Date 

                                                   President, Medical Staff

Effective Date : ____/____/_____

Reapproved : ____/_____/_____

Attachment A : Format of a Clinical Policy :

1. All clinical policies should contain the following headings :

          I.      Purpose

          II.     Policy Statement

          III.    Scope

          IV.    Definitions

          V.     Procedure 

          VI.    Owner :

          VII.   Builder :

          VIII.  Tested by :

          IX.     Keywords :

          X.      Approval Committee :

          XI.     Approval Date :

2. Should be formatted on 8.5" x 11"

3. Should be clearly labeled "CLINICAL POLICY - ACME HOSPITAL"

Attachment B : Format of the Clinical Policy Manual :

The clinical Policy Manual will be organized into the following sections and chapters :

1. SECTION I : HOSPITAL-WIDE CLINCIAL POLICIES

       a. Chapter 1 : General Clinical Policies     (Approved by Medical Executive Committee)

       b. Chapter 2 : Nursing Policies                  (Approved by Nursing Committee)

       c. Chapter 3 : Infection Control Policies    (Approved by Infection Control Committee)

       d. Chapter 4 : Laboratory Policies             (Approved by Laboratory Committee) 

       e. Chapter 5 : Pharmacy Policies               (Approved by P&T Committee)

       f. Chapter 6 : Radiology Policies               (Approved by Radiology Committee)

       g. Chapter 7 : HIM/Informatics Policies    (Approved by HIM/Informatics Committee)

2. SECTION II : DEPARTMENT-SPECIFIC CLINICAL POLICIES

        a. Chapter 1 : Medicine                            (Approved by Medicine Committee)

        b. Chapter 2 : Surgery / OR                     (Approved by Surgery Committee) 

        c. Chapter 3 : Pediatrics/Neonatal            (Approved by Pediatric/Neonatal Committee)

        d. Chapter 4 : Labor and Delivery           (Approved by L&D Committee)

        e. Chapter 5 : Behavioral Health             (Approved by Behavioral Health Committee)

        f. Chapter 6 : Pediatrics / Neonatal          (Approved by Pediatric Committee)
        g. Chapter 7 : Critical Care                      (Approved by Critical Care Committee)

Now remember, your hospital's Clinical Policy #1 may vary. 

To provide proper oversight, then, the President of your Medical Executive Committee should meet with all of these chairpersons on a regular basis (once every few weeks/months) to talk about the health of the policy mechanism and any issues which arise. If the committee minutes, from all of these committee meetings, are published in a central location - The minutes will then also help communicate the overall state of affairs on your front line to senior leaders. (In this way, your policy mechanism becomes a tool of organizational communication.)

Anyway... One of the first questions you'll get, after you examine this draft, is, "What about my policies?", for example, Quality Assurance might argue "We need QA policies that help guide the enforcement of error reporting...!"

Your Medical Staff President and Clinical Policy Coordinator will have two options, when faced with this argument from various places in your hospital :

1. Create a new chapter in your policy manual for QA policies (in this case, probably under hospital-wide clinical policies) :
     BENEFITS : 

             - QA will have their own chapter in the policy manual

             - They can approve QA policies without discussion at the Medical Executive Committee

     COSTS : 

             - You will need a new committee to approve the policies in this chapter

             - You will need a charter delegating authority to that committee

             - You will still need to oversee the subcommittee through regular meetings with the subcommittee chairperson.

  

2. Approve this sort of policy as a "General Clinical Policy" :

     BENEFITS : 

             - Fewer committees needed to maintain this manual = Less staff needed to fill committees!

     COSTS : 

             - Medical Executive Committee may spend time reviewing and approving many policies -

So : If Medical Executive Committee is spending too much time reviewing/approving QA policies, the Chairperson of the MEC should consider creating a QA subcommittee and approving a charter delegating that committee with the power to approve their own QA policies.

Would love to hear your feedback! Leave comments about your own Clinical Policy #1 stories! :)

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!