What is an Order Set?

It's funny. When I first got involved with electronic medical records at the Albany VA Hospital, as a resident, I remember one of their informatics people telling me, "You have no idea how political order sets are. The arguments I have seen over whether to check or uncheck a box... It's unbelievable."

She was right.

After you go electronic, prepare for the political discussions about order sets. Lots of people have opinions, but not many are actually are involved with building, testing, or development of order sets or using them.

So I thought I'd present this primer, to help people understand - "It's not just a bunch of orders with boxes." :

What is an Order Set?

I. BACKGROUND

An order set is a grouping of orders, used to standardize and expedite the ordering process for a common clinical scenario.

Before an order set can be created, the goal of the order set must be clear. Any necessary orders, contained in the order set, must be built first. (Order sets for new or innovative workflows should first be examined for any new orders that need to be engineered first.)

Order sets should only contain orders. They should not be confused with :

1. PROTOCOLS - Conditional IF/THEN statements, allowing a nurse/pharmacist/other licensed medical professional to start/modify/stop orders on behalf of a licensed physician, to automate and standardize the care for a common clinical scenario.
2. CLINICAL PATHWAYS - Tools used to standardize the discussion and goals of therapy, during rounds, for a common clinical diagnosis.
3. CHECKLISTS - Documentation tools used to document, standardize, and expedite the screening process for a common clinical scenario.
4. POLICIES - Agreed-upon standards for your organization
5. PROCEDURES - Detailed steps about how to achieve a desired standard.
6. PATIENT EDUCATION MODULES - Documents that help educate a patient about a particular subject (e.g. diet, disease, procedure, or aftercare)
7. STAFF EDUCATION MODULES - Documents that help educate a staff member about a particular subject (e.g. diet, disease, procedure, or aftercare)
8. DOCUMENTATION - Tools that help record and transmit patient history, condition, activities, responses, laboratory values, radiology images, and notes
9. GUIDELINES - Educational tools to help educate a staffmember about a general clinical objective (more flexible and negotiable than a policy)

For maximum safety, order sets should be built :

1. With clarity and a standard layout (Please see the ISMP Guidelines).
2. With all necessary information required to safely complete the order set.
3. With only those automating features which are absolutely necessary. (Risks/benefits of pre-checking orders must be closely examined on each order. As a general recommendation, pre-checking orders should be avoided on medication orders.)
4. With evidence-based practices.
5. To reduce variation and unintentional oversight.
6. To prompt for all necessary information.

Order sets can range widely in complexity, from very simple convenience order sets, to very complex order sets used to trigger clinical pathways or protocols.

II. DESIGN / CATEGORIZATION

Order sets typically fall into one of two primary categories :

1. Charge Order Sets - Those used by nurses and other clinical staff to create charges for common clinical materials (e.g. gauze, dressings, etc.)
2. Physician Order Sets - Those used by physicians to standardize and expedite the ordering process for a common clinical scenario.

Physician Order Sets may vary widely in complexity, but typically come in one of several types :

1. Admission Order Sets - (Sometimes called "Venue-specific order sets") - Used to admit a patient to a particular attending, level-of-care, and service.
2. Transfer Order Sets - Used to transfer a patient to a particular attending, level-of-care, and service (rarely used in clinical practice, but hypothetically these could be used to standardize care on transfer of a patient)
3. Discharge Order Sets - Used to discharge a patient from a particular level-of-care
4. Workup Order Sets - Used to workup a particular condition of complaint
5. Treatment/Diagnosis Order Sets - Used to standardize and expedite care orders for a common clinical diagnosis.
6. Prep (aka Pre-procedure or pre-operative) - Used to prepare a patient for a procedure or operation.
7. Recovery (aka Post-procedure or post-operative) - Used to recover a patient from a procedure or operation.
8. Convenience Order Sets - Used for another common clinical scenario, other than those in 1-7 above (e.g. nursing protocols, heparin titration protocol, alcohol withdrawal protocol, insulin titration protocol, vent liberation protocol, etc.)

More complex physician order sets may fall outside one of these categories.

III. OWNERSHIP

Order sets are typically owned by a defined clinical director.

IV.  CONSTRUCTION

Order sets should generally be constructed by a person trained/experienced in building order sets (e.g. clinical informaticist) in conjunction with a Subject Matter Expert (SME) and a Clinical IT Analyst.

V. TESTING

Order sets should be tested by all parties involved in the use and function of the order set. Generally, at a minimum :

1. One end-user physician should be able to understand and complete the order set
2. One end-user nurse should be able to understand and complete the orders from the order set

Additional users (e.g. Pharmacists, respiratory therapists, etc.) may be necessary for testing, depending on the type, complexity and goal of the order set. 

Testing needs shall be determined by the clinical Informaticist in conjunction with the chairperson of the Order Set Committee.

VI. APPROVAL

After testing is completed, the order set may be brought to a committee for approval. The chairperson of the Order Set Committee will put the order set on the agenda, and allow a period of comments from voting members before the order set is brought to a vote.

Voting will be conducted by the Order Set Committee Chairperson.

If the order set is approved by committee, the chairperson will forward the order set to the Clinical Analysts for publication.

In the event of a tie vote, the order set will be brought to the Medical Executive President for further discussion or placement on the Medical Executive Committee.

VII. PUBLICATION

After approval by committee, the order set will be published for use :

1. An electronic version will be published in the EMR Order Set Catalog.
2. A paper version will be published into the Emergency Downtime Order Set Folder
3. An electronic version will be published in the Printshop Order Set Catalog, for creation of any paper order sets needed for remaining paper functions.

VIII. EDUCATION

After publication, staff education on the existence, goal, and use of the order set is the responsibility of the owner.

It is helpful if users are made aware of order sets, how to use them, changes, and reasons for change.

IX. MONITORING

After publication, all order sets will be monitored by their owner.

X. CITATIONS

ISMP's Guidelines for Standard Order Sets : http://www.ismp.org/tools/guidelines/StandardOrderSets.pdf

How to Install an Informatics Policy Framework, and Why?

A common question I get asked is :

Q: "Dirk... We have over 600 different order sets... Now we can't save money on formulary costs, because the doctors still keep ordering the old antibiotics on the old order sets. What can I do?"

The answer is simply : You need to define your standards. By defining a standard way in which your order sets will be built, you can do a lot to "clean up the order set catalog".

STEP 1 : You will need to decide : Should we let doctors make their own order sets?

Pros : Less work to build order sets, and docs can build exactly what they want.

Cons : Less organizational control over standardizing care, less control over costs, higher maintenance costs.

If you decide 'we want to standardize our order sets', proceed to Step 2.

STEP 2 :  You will need to convince your medical staff of the need for such standards. Create the following policy, then bring it to your medical executive committee for approval as a "General Clinical Policy". This will allow you to have a chapter of informatics policies in your clinical policy manual, and then start building a number of informatics policies to fill that chapter.

POLICY NAME : Chapter of Informatics Policies

POLICY : "All patients at Acme Hospital will be cared for with clinical information tools developed according to policies outlined in the chapter of Clinical Informatics Policies."

DEFINITIONS :

Clinical Tools - Any documents or other tools used to guide the delivery of clinical care. These may include, but are not limited to : Policies, Procedures, Orders, Order Sets, Protocols, Documentation/Forms, Templates, Patient Education Modules, Staff Education Modules, Charters, Schedules,  and Minutes. 

PROCEDURE :

A. Staff will consult the chapter of Clinical Informatics Policies prior to the construction of any clinical tool.

B. Staff may ask the Director of Clinical Informatics for guidance if any questions arise regarding the construction of these tools.

If you've designed this correctly, and your medical staff understands the issues, this should generate some discussion before it gets approved.

STEP 3 : You will then need a committee to help approve the policies that go in that chapter of Clinical Informatics Policies. Develop a committee charter, and bring it to your medical staff for approval.

Charter : Clinical Informatics Committee

Meeting Frequency : Monthly

Jurisdiction : Reports to Medical Executive Committee

Purpose/Task : To approve Clinical Informatics Policies on behalf of the Medical Executive Committee

Quorum : 50%

Voting Structure : By majority

Chairperson : The CMIO

Voting Members : ___________, ___________, ____________, _____________ 

If you can't get this committee approved by your Medical Executive Committee, then you will need to bring all Clinical Informatics Policies to the MEC for approval.

STEP 4 : Come up with a standard policy definition for an order set.

"An order set is a grouping of orders used to expedite and standardize the ordering process for a common clinical scenario."

or...

"An order set is a document with a group of orders, used to expedite and standardize the ordering process for a common clinical scenario."

or even better yet...

"An order set is a document with a group of orders, with evidence-based links, that is used to expedite and standardize the ordering process for a common clinical scenario. All orders on an order set are started, modified, and stopped by a licensed physician."

Any of the above definitions should suffice, depending on your need for clarity.

STEP 5 : Use that definition to write your first good informatics policy, in your chapter of informatics policies, to standardize your order set development.

POLICY NAME : Order Set Development Policy 

POLICY : "All order sets will be built according to the procedure outlined below."

DEFINITIONS : 

Order Set - A document with a group of orders, with evidence-based links, that is used to expedite and standardize the ordering process for a common clinical scenario. 

PROCEDURE :

A. Order sets will be owned by a Clinical Director.

B. Order sets will be designed by an Informaticist and a Clinical IT Analyst.

C. Order sets will be tested by the Clinical Director and Informaticist and subject matter expert, using  at least (1) doctor and (1) nurse, in a testing environment.

D. Order sets will be presented by the Informaticist to the Chairperson of the Order Set Committee for placement on the Order Set Committee Agenda.

E. Order set creation, change, and deletion will be approved by the Order Set Committee at the next available meeting.

F. Order sets will be published in the Order Set Catalog in the Electronic Medical Record.

G. Order sets will be monitored by the Owner (Clinical Director). 

STEP 6 :  Bring the policy you wrote in Step 5 to your Clinical Informatics Committee (so they can approve it on behalf of your Medical Executive Committee), OR if you can't get your Med Exec to approve the committee charter, bring the policy to the Med Exec for approval.

Voila! If you were successful, you should now have :

1. A chapter of Clinical Informatics Policies, in your clinical policy manual, that has been approved by your Medical Executive Staff.
2. A charter giving authority to a Clinical Informatics Committee to approve Informatics Policies on behalf of the MEC.
3. Your first Clinical Informatics Policy outlining the steps required to build, test, approve, and publish a standardized, evidence-based order set. 
4. Your first meaningful change management mechanism for implementing electronic decision support and clinical workflows.

Once you have this rudimentary framework in place, you can then start working on updating the old 600 or more order sets. And if your order set committee is multidisciplinary and well-balanced, you can get balanced input before the order set goes live.

And your Informatics Committee can nimbly continue to develop informatics standards/policies that govern all of your clinical tool development.

This then brings you to Step 7 :

- Bring any old order sets to your order set committee for consideration of speedy deletion from your catalog.

- Build any new order sets according to the standard procedures outlined in the Order Set Development Policy (outlined above).

(You will probably need to tweak/format these policies to meet your organization's needs.)

I hope this was educational! Would love to hear how other folks handled their Informatics Policy framework! Remember, my advice is free, and as always, you get what you pay for. :)

What exactly is a Policy and a Procedure?

Got back from the HIMSS11 conference in Orlando. First, a few quick impressions :

1. It was BIG. Lots of vendors, lots of people. Everyone selling you "a solution". With this many vendors, it's almost impossible to find a standard. Lots of portable toys, but no clear agreements about what's going to run on those toys. Looks like the industry has a ways to go before being mature, and HITECH has made lots of people "get into the Health IT business".
2. No meaningful standards yet. The discussion on the PCAST report was particularly interesting, as people debated .CCR, .CCD, HL7, and other standards that either "didn't meet payor needs" or "didn't meet physician needs" or "didn't meet software needs". As the guy behind SpeakFlower.org, I can tell you nobody was addressing a standard that meets patient needs. 
3. The cabs and food were expensive. Taking a cab anywhere was $30 or more. Remember this the next time you book a hotel away from the convention center.
4. Lots of interesting people. Got into a robust debate with some tech and social media leaders about HITECH. My opinion : HITECH is going to drive small practices/hospitals to merge with larger practices/hospitals. Got into an interesting evening debate with some of those tech leaders, who seemed pretty blase and felt that was a necessary part of healthcare reform. Still, it underscores my belief that HITECH is about much more than just "let's get the docs to use computers".

Overall, definitely worth attending once, but remember - virtually everything at the conference is paid for with healthcare dollars. (If you want to save healthcare dollars, consider eating PB&J instead of a fancy dinner.) :)

Anyway, also at HIMSS, I spoke with several other informatics leaders who seemed puzzled by IT/Informatics governance, and how it relates to overall hospital governance.

To help, I thought I'd reinforce this basic informatics concept the same way I explained "What is Medicine Reconciliation, anyway?" -

So our lessons, for tonight, are "What exactly is a Policy?", "How is it different than a Procedure?", and finally, "What's the best way to make a policy / procedure?"

1. What exactly is a Policy?

A policy is a written goal of standardization for your organization. (E.g. "All patients will get low-salt meals." - The goal is to get low-salt meals to all of your patients.). It explains the who, what, when, where, and sometimes why.

A procedure is then the written steps it takes to get to that goal (E.g. "Step 1: Call kitchen  Step 2 : Order low-salt meal   Step 3 : Wait for meal to arrive") A procedure explains the how.

Both the policy and the associated procedure are generally kept on the same paper or electronic document, so that your employees can find and read those documents, and if they are written well, they will quickly understand :
    - What is the standard/goal of your organization?
    - How can he/she achieve this goal?

Writing a good policy statement is not easy. The focus has to be clarity. Short and sweet. In general, it shouldn't be more than one sentence - If it is, it's a warning sign that you may not have a clear goal.

A common mistake is to try to write several different policies into one policy - While it's tempting to do that to help avoid excessive committee discussion, putting several policies into one usually results in a policy that is unclear and ineffective.

So, some examples of unclear policy statements might be :

1. "Acme Hospital strives to provide low-salt meals which are nutritious and served warm and only to patients who need them. This is to meet the needs of the American Heart Association guidelines and other evidence-based recommendations. All employees will reinforce this rule."
2. "Acme hospital, to meet consumer demand, will make free parking available for any OB/GYN patients who are discharged." 
3. "Wiping feet before entering the hospital has been shown to save floor cleaning costs. Floor mats will be used by all employees before entering the hospital."

Their corresponding improvements would be :

1. "All CHF patients will receive low-salt meals."
2. "All OB/GYN patients will receive free parking vouchers on discharge."
3. "All employees will wipe their feet before entering the hospital."

Remember, the trick to writing a policy statement is clarity. To do this, you will need to know :

1. Who/what does the standard apply to?
2. What is the standard?

By defining both of these, you can use the following template to write a good policy statement :

                "[who/what does the standard apply to?] will [what is the standard?]"

And so you should only write a policy when :

1. You have a need to standardize something, and

2. You have the resources to enact and enforce the policy. (Just writing a good policy is not enough!)

Writing good policy requires proper balance between specificity and ambiguity. If you do it well, you will create clarity, and your policy manual will become a meaningful change management mechanism.

(I recommend "Writing Effective Policies and Procedures" by Nancy J. Campbell as a reference - It's really well-written and clear and provides ample education about how to write a good policy.)

2. How is it different from a Procedure?

If the policy is the goal, then the procedure is the steps it takes to get to the goal.

So, if we use the three policy statements we improved up above :

1. "All CHF patients will receive low-salt meals."
2. "All OB/GYN patients will receive free parking vouchers on discharge."
3. "All employees will wipe their feet before entering the hospital."

... then we can write clear procedures to achieve those goals :

Policy : "All CHF patients will receive low-salt meals."

Procedure :

1. Physicians will identify all patients with a CHF diagnosis on admission.
2. Physicians will communicate the full name/MRNO of all patients with CHF to the nurse.
3. Nurses will send the name/MRNO of all CHF patients to the kitchen with an order for a low-sodium meal.
4. Patients will wait for meal to arrive.

Policy : "All OB/GYN patients will receive free parking vouchers on discharge."

Procedure : 

1. Discharge Planners in OB/GYN department will place a free parking voucher in all discharge packets.
2. Nurses in OB/GYN department will review free parking voucher with all patients on discharge.
3. Patients in OB/GYN department who have not received a free parking vouchers will be provided one on request.

Policy : "All employees will wipe their feet before entering the hospital."

Procedure :

1. Maintenance staff will maintain a mat at the entrance to the hospital.
2. All employees, before entering, will stand on the mat and wipe their feet for 10 seconds before entering the hospital.
3. After wiping their feet, employees may enter the hospital.

Obviously, writing real policies will be more complicated, as you work to address the myriad of clinical, regulatory, and organizational challenges that you will face in running a modern hospital. 

The first pitfall about procedures is knowing the difference between :

1. A procedure kept in a policy document ("How do you achieve the goal?")
2. A procedure kept in a procedure manual (usually a nursing procedure manual, kept on most floors to help nurses review the best way to perform a particular procedure.)

If you're really fastidious, you can reference the procedure manual from your policy documents, so that you don't have to write the procedure over again (E.g. "Procedure to insert Foley : See procedure manual page 23 on 'Inserting Foleys'")

The problem with this approach is that while it may save you some time, you will still need to maintain both the procedure manual as well as your policy documents.

Another common pitfall of procedures is the "complicated procedure" where you have a bunch of complex, logical and conditional arguments, like :

Policy : Nurses will maintain blood sugars between 60 and 200 for all diabetic patients.

Procedure :

1. Nurse will check patient's fingerstick every 2 hours
2. If fingerstick < 60 then nurse will give 1 amp D50 IV and call physician
3. If fingerstick = 200 - 249 then nurse will give Insulin 2 units SQ
4. If fingerstick = 250 - 299 then nurse will give Insulin 4 units SQ
5. If fingerstick = 300 - 349 then nurse will give Insulin 6 units SQ
6. If patient becomes dizzy, nurse may call a rapid response.
7. Fingersticks may be checked more often for patients who feel dizzy.
8. If a nurse checks more than 4 fingersticks in a 2 hour period, nurses should call MD.

There are a few problems with writing this type of procedure :

1. It doesn't have a good "trigger" that makes a nurse start to follow these instructions.
2. It has a lot of "IF/THEN" statements. 
3. It also has a lot of orders in it ("give Insulin 4 units IV" requires an order to be placed in your EMR.)

These are all giveaways that this is not really a procedure, but a protocol. (Remember, a protocol is a series of instructions and well-defined conditions that allow a nurse/pharmacist to start/modify/stop an order on behalf of the protocol.)

So the way to clean this up is to make a procedure that says this :

Policy : Nurses will maintain blood sugars between 60 and 200 for all diabetic patients.

Procedure :

1. Physicians with diabetic patients will place an order for "Diabetic Protocol" in the EMR.
2. Physicians will verbally notify the nurse that an order for "Diabetic Protocol" has been entered.

This then lets you make a Diabetic Protocol :

1. Nurse will check patient's fingerstick every 2 hours and as needed
2.      If fingerstick < 60 then nurse will give 1 amp D50 IV and call physician
3.      If fingerstick = 200 - 249 then nurse will give Insulin 2 units SQ
4.      If fingerstick = 250 - 299 then nurse will give Insulin 4 units SQ
5.      If fingerstick = 300 - 349 then nurse will give Insulin 6 units SQ
6.      If a nurse checks more than 4 fingersticks in a 2 hour period, nurses will page MD
7. Nurses will check patients mentation every 2 hours
8.      If patient becomes dizzy, nurse will dial operator to call a rapid response.

3. What's the best way to make a policy / procedure?

The funny thing is, most people aren't aware of the cognitive processes behind their daily activities. For example, you've probably sent lots of emails, right?

You probably didn't think about the steps you took to send an email :

1. You owned the email - Your brain decided, "I need an email to accomplish a goal."
2. You built the email - You actually typed the text of the email
3. You tested the email - You looked at it to see whether it was fit to send
4. You approved the email - Your brain felt the email was good enough to accomplish the goal
5. You published the email - Your finger clicked the mouse on the "SEND" buttom
6. You monitored the email - You waited to see the effectiveness of the email - If no response, you will probably repeat at step #2

So writing a good policy requires the same steps : Ownership, construction/building, testing, approval, publication, and monitoring. Let's just quickly review these before we wrap up for tonight :

1. Policy Ownership - If the point of a policy is to set a goal/standard, and your leadership/directors are the ones setting and enforcing the goals/standards, then it makes sense for policies to be owned by a director/leader.
2. Policy construction/building - This can be someone with training in building policies. (At a minimum, they should read the book I mentioned above, or attend some classes in policy writing so they can help the owner have clear and effective policies.) Informaticists are generally pretty good at understanding the construction issues, but you may choose to have someone special just to write your policies.
3. Policy vetting / testing / reviewing - Before bringing the policy to a committee for approval, you may need to "vet" or "appraise, verify, or check for accuracy" the policy. Who you bring it to, before approval, should depend on the committee chairperson for the committee you are seeking to approve the policy.
4. Policy Approval - This generally should be done by a committee with expertise in approving the policies. (If the policy has been properly vetted, there should be little discussion at the approval committee.) The committee chairperson should put the policy on the agenda, and at the meeting conduct a vote for approval for the policy. If the committee approves, the chairperson should sign the policy to show committee approval.
5. Policy Publication - After approval, this generally should be done by putting the signed policy into a policy manual, and then surrounding the arrival with some education to staff about the new policy.
6. Policy monitoring - This generally should be done by the owner, so if there is a change/update that is needed, they can go back to step #2.

It is for these reasons, then, that I put on my propeller-hat and recommend the following headings for your policy documents (these are not standard, but I would use them if I were to design a policy manual): 

ORGANIZATION NAME

POLICY TITLE
CREATION DATE

I. PURPOSE :
II. POLICY STATEMENT :
III. SCOPE :
IV. DEFINITIONS :
V. PROCEDURE :
VI. OWNER :
VII. BUILDER :
VIII. CITATIONS : (This will help keep your policy manual evidence-based!)
IX. TESTED/VETTED BY :
X. APPROVAL COMMITTEE :
XI. APPROVAL DATE : (with chairperson signature)
XII. REVISION HISTORY :

Not everyone will have these headers, but if you're at the point of actually starting a policy manual, I think this could be really helpful in getting your organization to better understand these policy development, implementation, and maintenance issues.

Remember : My advice is free, and you get what you pay for. :)

(In all seriousness, this is how I might set up my policy headers and development process, but your mileage may vary.)

Would love to hear your thoughts/opinions! Please comment or ask questions - I would love to discuss other healthcare informatics issues! :)

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 Financial Costs of Hidden Protocols : How Regulatory Bodies Can Help

Know that very common tool known as the “Heparin protocol”? Whether your hospital is electronic, or paper-based, you probably have some version of it.

Take a good look at it. Is it titled “Heparin protocol”? Or “Heparin Order Set”?

Know the difference? Many people don’t. This is one of the hidden costs of healthcare that few people appreciate or understand.

A protocol is a document with a clear set of specific instructions, which allow a nurse, pharmacist, or other licensed medical professional to activate, modify, or discontinue a patient care order on behalf of the protocol. Any conditional (IF/THEN) statements should refer to well-described, discrete data elements. Protocols must be activated and deactivated by a physician order. Clinical protocols are commonly published internally in either an electronic or paper protocol manual.

An order set is a grouping of patient care orders (medication orders and other orders) to help expedite the ordering process for a common clinical scenario. Order sets are commonly published internally in either a paper printshop/order set catalog or an electronic medical record.

The problem is : Many hospitals confuse the definitions for these terms, and as a result, they engineer and publish protocols incorrectly. Instead of being published as protocols, they get designed, approved, and published as order sets.

Now look again at your order set. Are there any conditions that would make a nurse enter a new order, modify an existing order, or discontinue an order? “Discharge patient when criteria are met”, “This order should only be used in the ___”, “Advance diet as tolerated”, “If pain is uncontrolled, titrate IV to …” – Do you see any of those? If so, you may have protocols hidden in your order set.

Why is this a problem? Because protocols and order sets have different functionality, which brings unique engineering needs :

1. Order sets - Contain orders that are activated/modified/deactivated by a physician.
2. Protocols - Contain orders that are activated/modified/deactivated by a nurse/pharmacist. (based on a well-defined condition.)

The problem doesn’t just stop there. Protocols are sometimes confused with clinical policies.

A clinical policy is a written goal for a defined patient population. The clinical policy applies to the defined patients, from the time of approval to the time of discontinuation, both executed by an order of the President of the Medical Staff or an appointed chairperson.

A procedure is a written list of explicit instructions about how to achieve a particular goal. Procedures related to policy goals are commonly attached to policy documents and published in a policy manual. Procedures related to other goals are commonly published internally in either a paper or electronic procedure manual.

Now look at your clinical policies. Do you have protocols hidden in your policies?

What does this confusion cost a healthcare institution?

When the common clinical tools are not well-defined in hospital policies and charters, they can be poorly engineered. Poorly engineered clinical tools may not create their desired impact. This makes change management very challenging.

The cost of this confusion, unfortunately, generally goes unnoticed until an EMR (Electronic Medical Record) ultimately forces a hospital to contend with these definitions. In a paper world, the clinical environment will generally continue to function, even if the borders between all of these are blurry. In an electronic world, most software is not as forgiving as paper – Order sets appear in one place electronically, protocols appear in another, and policies appear in yet another. These may all need to be re-engineered to work electronically. (This is one of the reasons why hospitals see a performance benefit after they "go electronic".)

To contend with the management of these tools, even on paper, hospitals often designate committees to help review, approve, publish, and implement these tools. But because there are no widely-accepted standard definitions for these tools, the policies and committee charters that refer to these tools may be vague.

The net result : A committee that works to create a protocol, that mistakenly gets published as a policy, may not have the desired impact on front-line patient care. When this happens, the administrative costs of managing these tools can skyrocket, and those committees can feel powerless to make change. 

Why are there no widely-accepted standard definitions for these tools? Surprisingly, none of the common regulatory or standards organizations in American healthcare seem to publish nor endorse common definitions. So where did the above definitions come from? I wrote them.

As a result of this lack of definition, hospitals are forced to contend with these engineering issues individually. Some will navigate this easily. Others will not.

My recommendation would be for CMS and Joint Commission to announce the publication of standard policy definitions for these very common clinical tools. While some hospitals will initially contend with meeting the new definitions, the long-lasting efficiency to the American healthcare system will be enormous.

They are welcome to start with my definitions, which are free. (Remember, you get what you pay for.) :)

On the Importance of Policy Mechanisms and Governance

Healthcare is going through change. Tremendous change.

Pay-for-performance, ACOs, EMRs, and a rapidly growing buffet table of regulatory bodies are forcing hospitals to adapt, and quickly. Hospitals and medical systems that can change quickly, adopt new standards, implement new tools, and provide low-cost, high-quality care will survive. Those that can't, won't.

So recently I've had several conversations with healthcare leaders who are looking for help making change. Some of the questions I've heard :

1. "What can I do to help us make change faster?"
2. "Why aren't our physicians (or committees) engaged?"
3. "What can I do to help improve communication?"
4. "What can I do to help standardize care in our organization?"
5. "What can I do to help us work together as a team?"
6. "What can I do to help us implement our Electronic Medical Record?"

Believe it or not, all of these questions are related by a thing called "hospital governance", and probably the most important tool for hospital governance is your policy manual.

Q : "Dirk, what is hospital governance? It sounds like a civics lesson, or something from Schoolhouse Rock."

Every organization, from Apple to IBM to small businesses to hospitals, have some form of governance - A set of tools to make decisions and take actions. Why? Someone has to make decisions, and then someone has to get work done. Unfortunately, organizing those people, who may have conflicting opinions, and getting them instead to work together can be challenging.

It's not enough to just have "talented staff". If your staff isn't working together the way you want them to, it might be a sign that you need to look at your governance structure.

So what is the biggest tool you have to govern yourself? Your policy manual. Unfortunately, the governance, policy manual, and policy mechanism of most hospitals is probably one of the least taught subjects in healthcare management.

Bear with me, I'm going to explain it in simple language. :)

Q : "So, Dirk, what's a policy? What's a procedure?"

A policy is a written goal of your organization. The procedure is the list of steps you take to achieve that goal. 

Good policy statements are short and sweet and clear. (A really good reference for this is Writing Effective Policies and Procedures : A Step-by-Step Resource for Clear Communication, by Nancy J. Campbell, 1998). Policy statements should not be paragraphs long - One or two sentences maximum. They should be clear and confident, e.g. :

     "All patients will get kosher meals..." or

      "All ED patients will get screened for influenza..." or

       "All pediatric patients will get weighed daily..." or 

        "All female patients over age 40 will be offered screening for..."

(You'll notice all of the above samples refer to subsets of patients, so they are all samples of clinical policies.) Good policy statements create clarity out of confusion, and help your staff understand your organizational goals.

The procedure, then, are the steps you take to achieve the goal stated in the policy, e.g. :

   "All pediatric patients will be weighed using the following procedure :

          1. Patient will stand on a digital scale

          2. Nurse will read digital readout on scale 

          3. Nurse will document the patient's weight in the patient's chart."

If you're not used to writing policies, it pays to invest in someone with training and experience. A good policy writer is worth their weight in gold. It's part art, part language, part human behavior, part communication, and part understanding workflows enough to write a good policy. Good policy writers can help create clarity out of confusion, and save your organization lots of money.

And you'll know if you have a good policy because someone on your front-line staff can read it, clearly understand it, and feel educated by the policy. 

When should you make a policy for something? Anytime your organization needs to standardize something.
      - Need everyone to get weighed on admission? Write a policy.
      - Need all patients over 50 to be given cancer screening? Write a policy.
      - Need all order sets to look the same? Write a policy.
      - Implementing a new tool that everyone will use the same way? Write a policy.

The danger, of course, in bad policies is that sometimes you can write too much. If you write too much, you can "paint yourself into a corner". This can be a problem when a regulatory body comes to look at your policies - In general, they look to make sure your policies reflect your practice. If you write too much, you can end up with policies that are too long, or that don't reflect your current practice, or that you have to keep amending/updating too frequently.

Again, this is why you should invest in someone trained in the art of policy writing, to help you write short, well-constructed, thoughtful, and clear policies. 

Q : "Can you give me a good teaching example of a policy and procedure?"

Sure. My favorite teaching example is this one :

POLICY : All patients will get a cupcake on admission.


PROCEDURE :

1. Kitchen staff will bake 100 cupcakes daily.
2. Couriers will bring cupcakes to floors.
3. Nurses will hand patients a cupcake when they are admitted.

What I like about this teaching example is it shows the thought that needs to go into a good procedure -

• It is a simple example which, while somewhat comical, people usually don't forget.
• It shows which staff will play which role (this is very helpful when figuring out who should review a policy before it is approved)
• "100 cupcakes" - It shows the thought that needs to go into writing an effective procedure. The trick : to include as much detail as is needed, and no more - (How many cupcakes will you need a day? How many admissions do you usually have?) 

This simple, well-written policy then helps directors budget for the time of their employees, and finance people to budget for the materials needed to make this policy work.

Q : "So what about the policy manual?"

The policy manual, then, is your total collection of policies. It should be treated like a sacred text. A good policy manual isn't torture - It's a source of education and communication across your organization. 

     - Have new staff you need to train? Use your policy manual!
     - Have old staff that you need to train? Use your policy manual!

     - Have directors who need to know "what's happening on the front"? Use your policy manual!
     - Have staff who need to know what the organization's rules/objectives are? Use your policy manual!

Q : "That seems pretty simple, is that it?"

Hardly.

Q : "What else do I need to know?"

Everything you do with those policies determines how your organization functions.

1. The way you organize your policies is important.

In a large organization, it's not enough to simply put all policies into one binder. You'll want to make a table of contents that guide your front-line staff to the policies they are looking for. Often, you'll want hospital-wide policies (apply to patients regardless of location), and department-specific policies (apply to patients in a specific location). And then you'll want to subdivide those chapters. (See my post about Policy Manuals Made Easy for an example of how you might divide your policy manual.)

2. The way you test your policies is important.

Before your policies are brought to a committee for approval, you'll want the policy writer to "test" them. That means, you'll want to know that the policy has been checked for accuracy, that the workflows are realistic, that the spelling has been checked, that the formatting is correct, that the proper stakeholders have been asked about the policy.

If you test your policies properly, before they are brought to a committee, there will be little discussion at your committee. Ever hear the statement, "Why are we discussing these details in the committee meeting?" The more time you spend in the "testing phase", the less discussion there will be in committee. I can't say enough about the importance of investing in testing, before a policy is brought to a committee for approval.

3. The way you approve your policies is important.

Depending on how you organize your policy manual, you will need a committee, or a group of committees, to approve your policies. A well-designed committee is small, efficient, and has a well-designed voting structure, run by a committee chairperson who understands basic rules of parliament and chairperson responsibilities. (For this, I recommend Robert's Rules of Order : Newly Revised - In Brief.)

If your committee has a well-designed charter (and voting structure), and is run by a chairperson who understands their responsibilities, the approval process will be efficient and the committee will make good decisions - ultimately they need to decide whether to approve, deny, or modify a policy.

And if you organize your committee structure properly, then subcommittees that struggle to approve a policy, or end up in a tie vote, should usually have a top-level committee that can discuss all of the policies that cause extensive discussion.

4. The way you publish your policies is important.

It's not enough to have well-written, approved policies in a binder in someone's desk or laptop. The policy manual has to be organized, comprehensive, and put in a place where everyone can access it. 

Every employee should know where it is, and should be introduced to it when they are hired.

5. The way you enforce and monitor your policies is important.

It's not enough to have well-written, approved policies in an organized, common policy manual. Managers need to enforce policies. Sure, during emergencies, there may be exceptions/emergencies where your front-line staff violate a policy, but when that happens, the employee should document the reason and managers/directors should ask "Why?". If someone is repeatedly violating a policy, it either means the policy is not appropriate/realistic, not properly designed, or the employee may need educating. (In my opinion, violating a policy should never be an automatic black mark against the employee - It should make the manager pause to reflect on the reason for the violation.)

It's also not enough to just schedule a re-review of policies every 2-3 years. Enforcement and monitoring is a continuous, ongoing job, which hopefully your managers are doing continuously. Those managers should be well-connected to your policy mechanism, so they can respond appropriately.

Finally, I will leave you with this Top-10 list of overheard comments which suggest your policy/governance mechanism may not be working the way you want it to :

1. "Why aren't our committees (or physicians) more engaged?"
2. "I don't know how to make a change around here" or "We can't change anything."
3. "Why didn't they tell us they were doing that?" (or "They have no idea what we're doing.")
4. "Who the heck passed that policy?" (or "That policy makes no sense.")
5. "Where is the policy manual?"
6. "I didn't know I was supposed to do that."
7. "Why do we have so many order sets?" (or policies, or protocols, or forms...)
8. "Our committee just decided against that, why are people still doing it?"
9. "Why aren't the owners updating their policies?" (or, "These policies are so old.")
10. "What can we do to standardize care?"

The good news is that organizing a policy manual and mechanism, and fixing your governance, can be a great experience that draws your entire staff together and rallies the troops. Feel free to leave your own stories about policy mechanism and governance!