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

Are physician informaticists cost-effective?

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

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

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

I. BACKGROUND : HOW TO MAKE A CHANGE

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

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

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

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

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

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

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

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

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

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


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

II. IF YOU HAVE A NON-PHYSICIAN INFORMATICIST :

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

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

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

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

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

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

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

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

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

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

1. Owner = Hospitalist Director

2. Builder/Informaticist = Your physician informaticist

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

4. Subject Matter Expert = Your physician informaticist

5. Tester = Your physician informaticist

6. Approver = Your (order set committee)

7. Publisher = Your Clinical IT Analyst

8. Educator/Implementor = Your physician informaticist

9. Monitor = Your physician informaticist

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

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

ANOTHER OPTION : 

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

ANOTHER OPTION :

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

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

But again, this will mean :

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

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

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

This then sets up the following structure :

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

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

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

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

IV. IN CONCLUSION

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

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

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

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

What is a Procedure?

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

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

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

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

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

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

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

I. BACKGROUND

A procedure is a detailed series of steps that should be taken to accomplish a defined goal. It's the clear list of instructions.

1. It should not be confused with a protocol. Protocols contain the conditional (IF/THEN) statements that  allow a nurse, pharmacist, or other licensed health professional to start, modify, or stop an order on behalf of the protocol. Protocols are generally turned on/off with a physician order. 
2. It should not be confused with a policy. Policies are stated goals/standards for the organization. While some procedures are paired with policies ("Policies and Procedures"), the policy is only necessary if you wish to "mandate" use of the procedure. If a procedure is not paired with a policy, it is optional. If a procedure is paired with a policy, then it should be a standard of the organization.

For this reason, procedures are sometimes published :

1. With a policy - ("Policies and Procedures") - When use of the procedure is a "mandated organizational norm"
2. Without a policy (e.g. Nursing Procedure Manuals, commonly found on most patient floors) - When use of the procedure is an option

II. DESIGN / CATEGORIZATION

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

For best practice, it is helpful if each line of a procedure generally follows this format :

[ who ] will/may/should/must [ what ] [when] [where] [ why ] [ how ] 

Where :

[ who ] is the person who will perform that step in the procedure, generally best described by job title

will/may/should/must - Choose this wisely. Some people advise never to use "will" or "must" because it creates a very clear standard which can cause challenges if you fail to meet that standard. Speak to your organization's legal counsel for advice about this. 

[ what ] is the exact activity the person will perform

[ when] is the time they will do it (OPTIONAL - e.g. "Until hands are wet" or "After patient is comfortable", only if needed to clarify the procedure )

[ where ] is the location they will do it (OPTIONAL - only if needed to clarify the procedure)

[ why ] is the reason they should do this (OPTIONAL - only if needed to clarify the procedure)

[ how ] is a short description of the way they will do it (OPTIONAL - only if needed to clarify the procedure)

For example, one might write a procedure for washing hands :

1. Employee will approach sink
2. Employee will turn on water at sink until water is warm to touch
3. Employee will rub hands under warm water for 10 seconds
4. Employee will dispense 10mL of liquid soap into hands
5. Employee will rub hands together vigorously for 30 seconds
6. Employee will run hands under warm water for 20 seconds
7. Employee will turn off sink with elbows
8. Employee will dry hands with paper towel from paper towel dispenser
9. Employee will throw paper towel in garbage

This, of course, can be reformatted for simplicity as :

A. Employee will :

1. approach sink
2. turn on warm water
3. rub hands under warm water for 10 seconds
4. dispense 10 mL of liquid soap into hands
5. rub hands together vigorously for 30 seconds
6. run hands under warm water for 20 seconds
7. turn off sink with elbows
8. dry hands with paper towel from paper towel dispenser
9. throw paper towel in garbage

You will notice in the above examples that there are no "IF/THEN" statements. These are best kept to protocols, especially if the procedure involves a nurse/pharmacist/other licensed medical professional starting, modifying, or stopping an order on behalf of the physician.

Remember, that when writing a procedure, one should keep in mind : What will you use the procedure for?

1. Procedures can easily be converted into "instructions" for patients to use (e.g. if you want a patient to learn how to donate blood)
2. Procedures can easily be paired with "Policies" to mandate a particular way of doing things (in this way they help standardize care)
3. Procedures can be left alone, and published in a lone "Procedure Manual", to help your staff understand the best way to accomplish a particular goal.

It should also be asked : Do I need to write this procedure? As you can imagine, once you understand how to write a procedure, it can become tempting to write procedures for everything your organization does. I recommend you only write procedures when there is a :

1. Clear need to standardize a process (so you probably want to pair it with a policy)
2. Clear need to educate a process, but don't need it to be mandatory (in which case you probably want to publish it in a lone procedure manual or as a "set of instructions")

Finally, remember that many procedures can be quite complex. If there are multiple team members involved in accomplishing a particular goal, the "who" in each line should be clearly stated, preferrably by job title. For example :

1. Attending Physician will place order "Consult Gastroenterology" in patient's chart.
2. Attending Physician will contact GI Consultant to arrange for evaluation and consultation.
3. GI Consultant will evaluate patient
4. GI Consultant will order "Milk of Magnesia 30mL PO x1 dose STAT" in patient's chart.
5. Floor Nurse will give Milk of Magnesia as ordered

III. OWNERSHIP

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

IV. CONSTRUCTION

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

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

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

V. TESTING

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

After testing has been completed, the builder/policy writer/informaticist should examine the needs for the procedure, and decide whether :

1. The procedure should be paired with a policy and published in a policy and procedure manual
2. The procedure should be published in a lone procedure manual.

VI. APPROVAL

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

The committee should examine the goals of the procedure, testing results for the procedure, and the publication plan for the procedure :

1. Will it be paired with a policy?
2. Will it be published as a lone procedure?
3. Does it need to be converted to more patient-friendly "instructions"?

If the approval committee feels the procedure is evidence-based, well-tested, and safe, it should be brought to a vote.

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

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

VII. PUBLICATION

After approval by committee, procedures should be published immediately :

1. In a Policy and Procedure Manual - For those procedures paired with policies
2. In a Procedure Manual - (e.g. Nursing Procedure Manuals kept in many clinical areas) - For those lone procedures which do not require policy mandates

Both of these manuals should be kept in the open, in a common place, where all end-users can easily find and review them.

VIII. EDUCATION

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

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

IX. MONITORING

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

X. CITATIONS


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

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

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

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

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

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