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

Policy Manuals Made Easy

Hi folks. Happy new year! May 2011 be even better than 2010 was! :)

So I've been asked recently about where informatics policies should live, ideally, and I answered, "In the clinical policy manual."

That led to a follow-up question : "Dirk, what exactly is a clinical policy?"

This gets to the heart of a really interesting conversation about healthcare : The difference between a clinical policy and an administrative policy.

First, a word about policies in general.

Policies are probably one of the most misunderstood things in healthcare. Most doctors shudder when talk centers around, "We should make a policy for that" or "Do you know what the policy is for _______?".

A policy is a written, agreed-upon goal. (The "procedure", often attached to the same document, are the steps about how-to-get-to-that-goal.)

Policies, then, are your organization's written goals. That's why The Joint Commission asks about them, during inspections - They want to know how you organize, how you think, how you operate, etc. They also want to make sure the policies reflect the practices in your hospital.

Policies, if well-written, don't need to be painful. Policies help guide your staff behavior, they help communicate goals, and if they're well-written, they can also be used for training.

They also help protect your staff - Their activities are backed up by the organization's support for that behavior.

"Aha. So you were talking about maintaining policy manuals?"

That's right, I was. Thanks for reminding me. :)

So an interesting thing about healthcare, unlike private industries - We have two policy manuals, whereas most non-healthcare industries only have one.

"And what are those two policy manuals...?"

Interestingly, to maintain an average hospital, you need two general types of organizational control :

1. Clinical Policies - Those policies that refer to patients and patient care
2. Administrative Policies - Those policies that refer to employees and employee issues

Why do you need two? Well, an average healthcare organization is usually run by a Board of Trustees, who at some point made the decision, "We would like to run a hospital here."

To accomplish this, then, the Board usually needs :

1. A group of administrative people who are experts at running the hospital - Keeping it organized, hiring people, making sure supplies show up, paying the bills, setting up the budget, running the place, sending out bills to insurers, etc.
2. A group of clinical people who are experts at delivering patient care - Performing surgery, seeing patients, taking vitals, giving drugs, managing ventilators, etc.

And that's why most hospitals typically have two wings of government :

1. The Administrative Branch
2. The Clinical Branch

... and the policy manuals that are used to help run these two branches of government are :

1. The Administrative Policy Manual
2. The Clinical Policy Manual

"I see... So what else do I need to know?"

Well, to run an average hospital, then, you need to have both clinical and administrative policies that help guide your daily activities. The conflicts that sometimes arise, between these two branches of internal government, are sometimes very complicated - And, as a result, not every situation calls for a clear administrative or clinical policy.

"So how do I recognize an administrative policy from a clinical policy?"

An administrative policy statement usually refers to employees or employee issues, so they typically start with something like this :

"All employees at Acme Healthcare will..." or

"All physicians at Acme Healthcare will..." or

"All nurses at Acme Healthcare will..." or

"All ED staff at Acme Healthcare will..."

The collection of these administrative policies is typically kept in an administrative policy manual.

A clinical policy statement usually refers to patients or patient care issues, so they typically start with something like this :

"All patients at Acme Hospital will..." or

"All pediatric patients at Acme Hospital will..." or

"All ED patients at Acme Hospital will..." or

"All terminally ill patients at Acme Hospital will..."

The collection of these clinical policies is typically kept in a clinical policy manual.

"Aha. So how do you organize these policies, then?"

Every hospital has a slightly different way of organizing them, but I recommend a very simple system of organizing them :

1. Administrative Policy Manual

     a. General Hospital-Wide Administrative Policies

          - Human Resources

          - Safety

          - Information Management / Medical Records

          - Quality Management

          - (Other organizational administrative policies)

     b. Department-specific Administrative Policies

          - ED

          - Medicine

          - Surgery

          - OB/GYN

          - Pediatrics

          - (etc..)

2. Clinical Policy Manual

      a. General Hospital-Wide Clinical Policies

           - General Clinical Policies 

           - Quality Management

           - Nursing

           - Medical Records / Informatics

           - Laboratory

           - Radiology

           - Infection Control

           - Dietary

     b. Department-specific Clinical Policies

          - Medicine

          - Surgery / OR

          - OB/GYN

          - Pediatrics

          - ICU

          - (etc. etc.)

Again, as I said, every hospital does this a little differently, to address their different needs, but the general theme is that they are all generally clinical or administrative policies, and they generally either apply throughout the hospital or in a specific department or physical area.

"Dirk... That sounds like a lot of work, then!"

It is a lot of work. If every policy has to be approved by a person or committee, there's a lot of work that goes into maintaining these policy manuals. Many hospitals struggle with doing this efficiently.

The good news is that it doesn't have to be torture. By delegating each branch of policies to the right person/committee, you can divide up the work efficiently, for example :

1. Clinical Policies

      a. Hospital-wide Clinical Policies

           - General Clinical Policies = Approved by Medical Executive Committee

           - Nursing Policies = Approved by Nursing Committee

           - Medical Records / Informatics = Approved by Med Rec / Informatics committee

           - Pharmacy Policies = Approved by P&T Committee

           - Infection Control Policies = Approved by Infection Control Committee

      b. Department-specific Clinical Policies

           - Medicine - Approved by Medicine Committee

           - Surgery / OR - Approved by OR/Surgery Committee

           - ICU = Approved by Critical Care Committee

           - Pediatrics = Approved by Pediatric Committee

You'll notice the theme : Every branch of clinical policies will either need a committee or a person, delegated to maintain and approve that particular chapter of the policy manual.

And you'll notice how much work it takes to maintain all of this. Every time a drug gets recalled, every time the government creates new billing standards, policies have to be adjusted and re-approved.

The good news, if you do this well, is that you can use the policy manual as an education tool :

- For new staff who are orienting to your hospital

- For existing staff who would like to quickly find out daily operations

Finally, an important part about maintaining all of these separate chapters is that even if you delegate the maintenance of these chapters to different committees, it's imperative that you publish all of these policies in the same place. (That means, that all "active policies" are kept in one common place, where everyone can look at them.) By keeping the entire manual (all chapters) in one place, it :

1. Helps avoid policy conflicts between different departments, and
2. Helps make the policy manual a tool of organization and education for your staff.

Again, as I've said before, my advice is free and you get what you pay for. Every hospital does this a little differently, but I hope I've communicated the major themes. Would love to hear your stories and thoughts about best ways to organize a clinical and administrative policy manual!

The problem of "Feature Bleed"

Another common question I get asked is, "What can we do to prepare for 'going electronic'?"

Most hospitals will, in these times, gather their order sets, in the hope of "making them electronic".

It's then, that you may notice the first problem. I like to call it "Feature Bleed".

"Feature Bleed" is when you have order sets that have pieces of :

1. Order sets
2. Protocols
3. Documentation

This is VERY, VERY common - Most paper-based hospitals aren't disciplined enough to have their order sets and protocols and documentation well-separated.

Take a look at your paper order sets - See something called "Advance Diet as tolerated" or "Up ad lib" or "Do not start any other CNS depressants without checking with the anesthesiologist first"? These are all protocols!

Take another look at your paper order sets - See something like "Write patent's PTT here : ___ ___ ___" or "Write patient's neuro checks q6h here : ____ ____ ____" - These are all documents!

Take one last look at your paper order sets - Are they labelled something like "Alcohol Withdrawal Protocol / Order set / Flowsheet"? This is a sign that you may have feature bleed. (Ask yourself which tab in the paper chart you have been putting this order set into - If you're not sure, that's a warning sign of "Feature Bleed")

How does this happen, and why is it so common? In the paper world, it's very easy to make an order set where :

[ Order set ] = [ Order set ] + [ Documentation ] + [ Protocol ]

The problem is, when you go electronic, you will have different places ("buckets") where you need to organize those things.

1. The "Order set" bucket
2. The "Protocol" bucket
3. The "Documentation" bucket

And to organize this, it will mean :

1. Significant redesign of your paper order sets
2. Significant redesign of your clinical protocols
3. Significant redesign of your clinical documentation

And to handle this? You'll need to define, for each of these informational tools :

1. A good policy definition of the informational tool (to help guide builders in the right direction and prevent future "Feature Bleed")
2. How will the informational tool be built? (By who, and how? What format?)
3. How will the informational tool be tested before it "goes live"?
4. How will the informational tool be approved in your organization?
5. How will the informational tool be published
6. How will the informational tool be tracked.

If your organization was very disciplined in the paper world, and you have good policy definitions of these tools, your conversion to EMR will go a lot easier.

And if not, you're like about 80% of the places I talk to. :) Just be prepared to deal with this organizational redesign issue at some point - Preferrably earlier, rather than later.