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's in the Informatics Toolbelt?

QUESTION : Dirk... How do I make change in a clinical setting?

A lot of modern healthcare asks for standardization. Common questions I get asked are focused on change and standardization, such as:

1. "How can we make sure the doctors use the order sets?"
2. "How can we make sure the doctors document ______ properly?"
3. "How can we make sure the doctors enter orders for ventilator changes?"
4. "How can we make sure the nurses document the vitals properly?"
5. "How can we make sure the pharmacists document the medication substitutions properly?"

The first tool most people reach for, to standardize care, is the order set. As a result, order sets are notoriously political. In the paper world, they generated enough debate, but in the electronic world, it often gets worse, as the political power shifts from a physician-centered process to a more organization-wide process.

Question : Huh? Dirk? Electronic order sets have a different political structure than paper order sets?

The short answer is yes. Why?

In a paper order set, most hospitals let doctors type their commonly-used orders on a piece of paper, put little check boxes next to each order, and a committee reviewed them - if the group of orders looked safe and met the right formatting requirements, and didn't have any unapproved abbreviations, the order set was generally approved, and the doctors could use them. End of discussion, for the most part, until the order set had to be updated. The doctors wrote what they wanted, and the organization approved them as long as there wasn't any major safety or organizational problem.

In an electronic order set, every electronic order (in the order set) has to be built by a programmer. So quite often, those programmers design the orders with extensive safety in mind. To figure out how to make them safer and more effective, the programmers ask the entire team (not just the doctor) for advice on how the order should be built. So programmers may ask the pharmacists, "How can we make this order safer?". They may ask the respiratory therapists, "What should this order look like?". They might ask the nurses, "What should the doctors really be asking for in this order?". They might ask the dietitians, "What should a diet order look like?". They might even add evidence-based links to the orders, on the order sets, to help guide the physicians about when best to use which orders.

As a result of these discussions with all of these different parts of the hospital, it's not uncommon for the programmers to design the electronic orders to look and behave differently than the paper orders did.

For example, a common safety tool used by programmers, after these discussions, is to build mandatory fields into the orders, that the doctors have to complete for the order to be accepted. As a result, the doctors are suddenly forced to think differently about these electronic orders, than they used to think about the paper orders.

I know it's still still sort of complicated, but a good example of this phenomenon is the diet order.

1. In the paper world, most paper order sets simply refer to an order, "REGULAR DIET".
2. In the electronic world, however, after discussion with speech therapists and dietitians, many electronic diet orders are built with mandatory fields for texture and liquid modification, so a doctor HAS to think about texture and liquid modification just to be able to enter a diet order. As a result, many electronic diet orders, on an electronic order set, will refer to the diet order, "REGULAR DIET, NO TEXTURE MODIFICATION, NO LIQUID MODIFICATION".

So doctors moving from the paper world to the electronic world will generally sense this loss of control - Suddenly, dietitians and pharmacists and radiologists can have enormous impact on the way they order something. In the paper world, doctors could simply write whatever they felt was best.

As a natural result of this political shift, electronic order sets often generate even more political discussion and debate than the paper order sets did. And this is another reason you may want to hire a CMIO, to help guide your doctors past the political debates and focus on good patient care.

Question : Aha. Interesting... Never thought about that. So what about this "Informatics Toolbelt" you mentioned?

The reason I bring up the "Informatics toolbelt" is because, as a hospital tries to standardize care by crafting workflows, everyone seems to reflexively reach for one tool : The order sets. By fixing the order sets, we can standardize care, right?

While order sets are certainly a good tool to help standardize care, they are not the only tool. Just to remind you that there are other tools, I present the following list of tools which I think sit in the Informatics Toolbelt : (Remember, most of these tools can be published either on paper or electronically...)

1. An order - A medicolegal instruction to provide a defined portion of patient care, via a defined route, at a defined rate, for a defined period of time. (Remember, in the paper world, you didn't have to "build" orders - In the electronic world, you have to "build" them, so you can actually engineer them to your advantage - The source of much political debate.)
2. An order set - A grouping of orders, to help standardize and expedite the ordering process for a common clinical scenario. Physicians generally start, modify, and stop the orders on an order set.
3. A protocol - A document that allows a nurse or pharmacist to start, modify, or stop orders based on a well-defined clinical condition.
4. A guideline - (aka care plan, etc.) A document that educates care team members about desired outcomes and processes, but generally carry less medicolegal weight than a protocol or policy, more negotiable, so they are engineered differently.
5. A policy (clinical or administrative) - A defined organizational goal or rule. 
6. A procedure - The steps requires to achieve a goal (or policy).
7. Documentation - (aka a forms, a flowsheet, etc.) - A permanent recording of patient status, activities, responses, and outcomes in time, authenticated by the signature of a licensed medical professional.
8. A patient education module - A document with media (written, video, or other) that explains a defined set of educational objectives to patients.
9. A staff education module - A document with material (written, video, or other) that explains a defined set of educational objectives to staff members.
10. A committee charter - By creating a charter, you can create a committee that helps standardize your care and monitor your processes
11. Committee minutes - By creating minutes, you can show effective supervision and committee activity to meet the organization's goals.
12. A staff meeting - Can be helpful for education and organizational purposes.
13. Email, paper mail - Can also be helpful for educational purposes.

There are probably other tools to put into the Informatics Toolbelt, but these are the most common ones. And a good informaticist can help you figure out the right mix of tools to craft the workflows you want to create to improve safety and standardize care.

(Using these tools to craft a workflow, in the electronic world, is an art known as electronic decision support. This is why a clinical informaticist is a key role in managing your clinical processes in the electronic world.)

Hope this helped remind you that order sets are a good tool to help craft a workflow and standardize care, but not the only tool. If you forget about the other tools, you may be missing out on other opportunities. A good clinical informaticist will help you figure out which tools to use for which scenarios. :)